Proposal: Goose support for CodeQL

Goose is a memory-safe systems programming language (Apache-2.0, .goose files) with no heap allocator, no garbage collector and no lifetime annotations. It is under active development, and its repository includes a tree-sitter grammar (tree-sitter/grammar.js).

CodeQL has no Goose extractor, so Goose code gets no static analysis in Code scanning.

As a stop-gap I built a small, unofficial checker that reports through SARIF and uploads with github/codeql-action/upload-sarif: https://github.com/flisk-sh/codeql-goose. It is not an extractor. It uses a lexer and looks at call shapes only, with three rules for now (a discarded bool from file and environment calls, paths outside the project root, literal secrets). It has not yet been run on a real project outside its own tests, and it will miss a lot.

Questions for maintainers

Is support for new, small languages like Goose in scope for CodeQL, and is there a bar (for example a stable grammar or a user base)?
Would the Goose tree-sitter grammar be a reasonable starting point for an extractor?
Until then, is uploading SARIF from an external analyzer the supported path?

I'm not asking for a merge into CodeQL. I'm not affiliated with the Goose authors. This is a related proposal to #22881 (Starlark).

Update: the stop-gap analyzer is now published on the GitHub Marketplace as an unofficial community action:

Marketplace: https://github.com/marketplace/actions/goose-analyzer-for-code-scanning-unofficial (v0.2.0)
Source: https://github.com/flisk-sh/codeql-goose

It is still not an extractor, and not made or endorsed by GitHub, the CodeQL team or the Goose authors. It uses a small lexer and a few call-shape rules, and uploads SARIF with github/codeql-action/upload-sarif. So far it has only been tried on small test files and on 37 of the Goose project's own sample and standard library files, where it reported nothing. The questions in the description are unchanged.

Is support for new, small languages like Goose in scope for CodeQL, and is there a bar (for example a stable grammar or a user base)?

There is no easy answer to this, see also #21062 (comment).

Would the Goose tree-sitter grammar be a reasonable starting point for an extractor?

If the Goose tree-sitter grammar is of reasonable quality, that would we a possible starting point. The Ruby extractor is built around a tree-sitter grammar.

Until then, is uploading SARIF from an external analyzer the supported path?

This is already possible.

Navigation Menu

Repository navigation

Proposal: Goose support for CodeQL #22882