Back to GitHub.com
Home Bounties CodeQL Research Advisories Get Involved Events

Bounties

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

  1. Write a CodeQL query that models a vulnerability you’re interested in.
  2. 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.
  3. 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.
  4. Open a pull request in the CodeQL repo with your CodeQL query. See the contribution guidelines for more details.
  5. 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.
  6. 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

  1. 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.
  2. Before requesting a bounty, you should first coordinate disclosure of any vulnerabilities that you are aware of with the maintainers of the affected projects.
  3. 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 experimental folder. For example here.
  4. 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 include details of any vulnerabilities found by your query, as a list of CVEs. To be considered, your query must find at least one CVE that was not previously found by an existing query, in a released version (older releases are also permitted) of an open source project that is actually used (no demo, training, vulnerable on purpose). Submissions without at least one result won't be considered. In case of a new CVE, don't create an issue until the coordinated disclosure process for those vulnerabilities is complete, because the issue will be publicly visible.
  5. 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).
  6. 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.

Note that while we welcome query improvements as part of this program, they are also subject to this eligibility criterion as any other submission.

FAQ

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:

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.

Pay attention however that some improvements are too simple to meet our minimum complexity requirements for eligibility to the All for One bounty. We still welcome these improvements as PRs to the CodeQL repo, but will not consider them for a bounty reward.

What if I do not want my submission published on the bounty website or do not have a GitHub account?

You can contact us via a DM on Twitter @GHSecurityLab. We will keep your name anonymous but the details of the report and the query will be public, subject to our coordinated disclosure policy.

My query finds a new vulnerability for which I didn't request a CVE, can I still submit a bounty request? Why do you require a CVE? Is the CVE requirement mandatory?

We ask that you always request a CVE. CVEs are instrumental to share information about known vulnerabilities across the open source ecosystem, and requesting a CVE contributes to our mission of scaling security research by notifying the community of existing occurrences, as much as creating a CodeQL query to protect the community from future ones. Additionally, we can use the CVE CVSS score to inform the scoring of the security factors of your submission and reduce any subjective bias.

The CVE process can sometimes take a long time. If you are concerned that someone else might claim a bounty for the same query in the meantime, you can still submit the bounty request with the PR, without disclosing details on the vulnerabilities you found, but it will not be considered for evaluation until a CVE is issued and added to the issue. Reach out to us privately to provide evidence of the vulnerabilities and of the disclosure in progress.

If you cannot obtain a CVE (private source code, or other exceptional cases), reach out to us privately.

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.

I want to propose a useful query improvement, but it's too simple to meet the eligibility requirement. What should I do?

PRs are welcome in the CodeQL repo for any query improvement, even if they are not eligible for bounty rewards. Community members regularly propose such improvements without submitting through the bounty program.