Using custom queries with the CodeQL CLI¶
You can customize your CodeQL analyses by writing your own queries to highlight specific vulnerabilities or errors.
This topic is specifically about writing queries to use with the database analyze command to produce interpreted results.
Other query-running commands
Queries run with
database analyzehave strict metadata requirements. You can also execute queries using the following plumbing-level subcommands:
- database run-queries, which outputs non-interpreted results in an intermediate binary format called BQRS.
- query run, which will output BQRS files, or print results tables directly to the command line. Viewing results directly in the command line may be useful for iterative query development using the CLI.
Queries run with these commands don’t have the same metadata requirements. However, to save human-readable data you have to process each BQRS results file using the bqrs decode plumbing subcommand. Therefore, for most use cases it’s easiest to use
database analyzeto directly generate interpreted results.
Writing a valid query¶
Before running a custom analysis you need to write a valid query, and save it in
a file with a .ql extension. There is extensive documentation available to
help you write queries. For more information, see “CodeQL queries.”
Including query metadata¶
Query metadata is included at the top of each query file. It provides users with information about the query, and tells the CodeQL CLI how to process the query results.
When running queries with the database analyze command, you must include the
following two properties to ensure that the results are interpreted correctly:
- Query identifier (
@id): a sequence of words composed of lowercase letters or digits, delimited by/or-, identifying and classifying the query. - Query type (
@kind): identifies the query as a simple alert (@kind problem), an alert documented by a sequence of code locations (@kind path-problem), for extractor troubleshooting (@kind diagnostic), or a summary metric (@kind metricand@tags summary).
For more information about these metadata properties, see “Metadata for CodeQL queries” and the Query metadata style guide.
Note
Metadata requirements may differ if you want to use your query with other applications. For more information, see “Metadata for CodeQL queries .”
Packaging custom QL queries¶
Note
The CodeQL package management functionality, including CodeQL packs, is currently available as a beta release and is subject to change. During the beta release, CodeQL packs are available only using GitHub Packages - the GitHub Container registry. To use this beta functionality, install the beta release of the CodeQL CLI bundle from: https://github.com/github/codeql-action/releases/tag/codeql-bundle-v2.6.0-beta.1.
When you write your own queries, you should save them in a custom QL pack directory. When you are ready to share your queries with other users, you can publish the pack as a CodeQL pack to GitHub Packages - the GitHub Container registry.
QL packs organize the files used in CodeQL analysis and can store queries,
library files, query suites, and important metadata. Their root directory must
contain a file named qlpack.yml. Your custom queries should be saved in the
QL pack root, or its subdirectories.
For each QL pack, the qlpack.yml file includes information that tells CodeQL
how to compile the queries, which other CodeQL packs and libraries the pack
depends on, and where to find query suite definitions. For more information
about what to include in this file, see “About QL packs.”
CodeQL packages are used to create, share, depend on, and run CodeQL queries and libraries. You can publish your own CodeQL packages and download ones created by others via the the Container registry. For further information see “About CodeQL packs.”
Contributing to the CodeQL repository¶
If you would like to share your query with other CodeQL users, you can open a pull request in the CodeQL repository. For further information, see Contributing to CodeQL.