Repository navigation
Proposal: Goose support for CodeQL #22882
Description
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).
Activity
kburym commentedon Oct 23, 2026
Update: the stop-gap analyzer is now published on the GitHub Marketplace as an unofficial community action:
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.jketema commentedon Oct 23, 2026
There is no easy answer to this, see also #21062 (comment).
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.
This is already possible.