To reward and incentivize contributions from the open source community, GitHub Security Lab is launching a bounty program. We pay bounties for new vulnerabilities you find in open source software using CodeQL.
The Bug Slayer (discover a new vulnerability)
Write a new CodeQL query that finds multiple vulnerabilities in open source software.
How to participate
- Write a CodeQL query that models a vulnerability you’re interested in.
- Run your query on real world open source software and find at least four vulnerabilities, preferably across multiple projects. Please note that projects which purposely include a vulnerability pattern for testing purposes are considered out of scope.
- Report the vulnerabilities to the projects' maintainers, help them fix them, and have them obtain CVEs for each one. Remember that for most open source projects, maintainers can now get a CVE directly from GitHub via Security Advisories. To be eligible for a bounty, you must first coordinate disclosure of the vulnerabilities with the maintainers of the projects.
- Open a pull request in the CodeQL repo with your CodeQL query. See the contribution guidelines for more details.
- Create an issue using the bug slayer template. The issue should link to your pull request and contain a detailed report of the vulnerabilities your query finds. Mention only the vulnerabilities that have been publicly disclosed and fixed. It should include a description of the vulnerabilities, their associated CVEs, and how the query allowed you to find them. Pull requests without an accompanying issue cannot be considered.
- An award of up to $5000 USD will be granted. We consider the impact and risk associated with the vulnerability and the quality of your query when determining the award amount.
All for one, one for all (add a new query)
Write a CodeQL query that is merged into the CodeQL repository. Such queries must identify a class of vulnerabilities (often linked to a CWE) with a high precision (i.e., a low false positive rate).
How to participate
- Write a CodeQL query that models a vulnerability class not currently covered by the current queries, or improve an existing query and extend its coverage to detect additional vulnerabilities. Use the contribution guidelines in the CodeQL repo.
- Before requesting a bounty, you should first coordinate disclosure of any vulnerabilities that you are aware of with the maintainers of the affected projects.
Open a pull request in the official query repo with a single CodeQL query (For Go, please use the codeql-go repository).
Please write all of your proposed code (including libraries) in the
experimentalfolder. For example here.
- Create an issue using the all for one template and a detailed report on the class of vulnerabilities your query is intended to find. Pull requests without an accompanying issue cannot be considered. The issue should also include details of any vulnerabilities that you found with the query. To be considered, your query must find at least one useful result on some revision of a real project. Submissions without at least one result won't be considered. Don't create an issue until the coordinated disclosure process for those vulnerabilities is complete, because the issue will be publicly visible.
- Work with the CodeQL team to verify the quality of your query. We will assess if the query meets the standards to be included in the CodeQL repo, or whether improvements are required. Queries must meet at least the requirements for experimental queries, including at least one useful result on some revision of a real project. Higher bounties will be awarded for queries that also meet additional requirements for supported queries, including query help and tests. In case you are improving an existing query, your submission must meet at least the requirements met by the existing query (if the existing query is already a supported query, your submission must meet the requirements for supported queries).
- An award of up to $6000 USD will be granted. We consider the impact and risk associated with the vulnerability and the quality of your query and documentation when determining the award amount.
Out of Scope
To be eligible for a bounty, queries must be non-trivial, and meet a minimum complexity requirement. More concretely, queries that simply look for one or two AST elements, or that could be easily implemented with a linter or simple grep, may not be considered interesting enough for a bounty. Queries must also be sufficiently general to cover a class of vulnerabilities and may not be tailored to a specific CVE.
A good way to ensure that your queries meet this requirement is to ensure it uses some more advanced analysis, like data-flow or control-flow.
What happens if my submission collides with another submission?
Bounty submissions are evaluated in the order they are received. In the case of a collision between submissions that are very similar, the first received submission will receive precedence for bounty award consideration. If a bounty is awarded to the first received submission, this makes any colliding submissions ineligible for award. However, if the first received submission is rejected, any colliding submissions will then be considered according to the same evaluation process by order of arrival.
Note: a query collision here is defined as queries that find the same, or near-same true positive set of results.
How does GitHub determine the amount of a bounty award?
The GitHub Security Lab and CodeQL teams consider the following factors when setting a bounty award:
- The complexity of the vulnerabilities
- The severity of the vulnerabilities
- The prevalence of the vulnerabilities: the number of impacted users and systems
- The performance and reliability of the query: its false positive rate
- The documentation of the query
- Whether you produce a blog post / write-up about the vulnerabilities and query to help share your experience
We welcome all query submissions and are happy to provide feedback on submissions.
Is the bounty award less for improving a query than for writing a new query?
Not as a rule, as several factors (see above) are considered. The quality of the query (performance, reliability, documentation) will likely be scored less than for a new query. But it may be the case that the new vulnerabilities
discovered by your improvement are more complex, and/or impact more users and systems than the original ones, which will give you a better score on these factors. Another frequent example is adding a new
source to a
dataflow query: there is a good chance that this query gets minimal scores on all the factors, resulting in a minimal reward. Another frequent example is adding a new `source` to a dataflow query: there is a good chance that
this query gets minimal scores on all the factors, resulting in a minimal reward.
What if I do not want my submission published on the bounty website or do not have a GitHub account?
My Pull Request has been merged but my bounty was rejected. Is this normal?
While rare, this does happen on occasion. The bounty program is specifically focused on helping secure open source at scale and adheres to strict guidelines for evaluation of bounty award. We grant rewards for queries that
demonstrably find real world security problems with a low false positive ratio. In some cases your query might only apply to a very application specific threat model, or may not yield any real world results. However, this query
might still be interesting from a QL community perspective due to the quality of the query at the CodeQL level and may be helpful to other CodeQL users. In those cases the CodeQL team might still merge your query into the
experimental community query folder even though it was not eligible for a security bounty award.
What if I disagree with the Security Lab evaluation? Can I challenge it?
When you disagree with the assessment of your query (for example on the exploitability of the detected vulnerabilities), do raise the concern, and the Security Lab member will get additional opinions to confirm or update their assessment. Note that in most cases your submission already goes through several team members, ensuring a fair evaluation.