← Code scanning (SAST)CodeQL
GitHub's semantic code analysis: code becomes a database, queries do interprocedural taint tracking.
github.com/github/codeql ↗- Stars
- ★ 10,182
- License
- MIT
- Language
- CodeQL
- Latest release
- No releases
- Last push
- 9 Oct 2026
ghtier ratingRated 4 of 5, Recommended4/5 · Recommended
The deepest analysis here and built into GitHub, but slow and only free for public repositories.
How it works
CodeQL first extracts a relational database from the code. For compiled languages it watches the build, for others it reads the source. Queries written in QL then run against that database, with libraries for interprocedural dataflow and taint tracking from sources (request data, event fields) to sinks (queries, shells, file paths).
On GitHub you turn it on with default setup in the repository settings or with github/codeql-action in a workflow, and results appear as code scanning alerts on PRs. Since April 2025 it also analyzes GitHub Actions workflows for injection, missing permissions and untrusted checkouts.
The queries in github/codeql are MIT licensed. The CLI and engine are under the GitHub CodeQL Terms: free for open source and research, and for private repositories it needs GitHub Code Security.
What it catches
- Injection and path traversal across function and file boundaries
- Unsafe deserialization and SSRF
- Script injection and untrusted checkout in Actions workflows
- Custom variant analysis written as your own queries
Run it
gh extension install github/gh-codeql
gh codeql database create db --language=javascript
gh codeql database analyze db --format=sarif-latest --output=codeql.sarif
What leaves your machine
Local analysis sends nothing. On GitHub, results are uploaded as code scanning alerts.
Limits
- Analysis takes minutes to an hour on large codebases.
- Private repositories need a paid GitHub Code Security license.
- Writing QL queries is a skill of its own.
Related incidents
OrganizationOngoing
"Pwn requests": pull_request_target & workflow_run
The structural flaw behind most of the incidents on this page. pull_request deliberately withholds write permissions and secrets; pull_request_target was created to restore them, and becomes hazardous the moment maintainers treat it as a normal CI trigger. workflow_run carries the same risk and gets far less attention: the triggered workflow can access secrets and write tokens even when the workflow that triggered it could not. One industry scan found 38% of organizations have a workflow vulnerable to script injection or dangerous triggers. Since 8 December 2025, pull_request_target always runs the workflow file from the default branch and checks out the default branch, whatever branch the pull request targets. That closes attacks through an old, vulnerable workflow left on another branch. It does not help when the default branch workflow itself checks out and runs the pull request's code.
Click to open →GitHub stats as of 10 Oct 2026. How ratings work.