skip to content
Back to GitHub.com
Home Bounties Research Advisories CodeQL Wall of Fame Get Involved Events

Bounties

The CodeQL Bug Bounty program operated by the GitHub Security Lab aims at scaling the security research community’s work across open source projects. The All For One protects against future vulnerabilities by coding and eradicating a pattern, while the Bug Slayer fixes existing occurrences of this pattern.

A bounty hunter can apply to both programs sequentially to maximize their positive impact on open source projects, and their gain.

mona puzzle

NEW: CodeQL support for Ruby is now generally available!

With CodeQL for Ruby out of Beta, GitHub Security Lab is including it as part of the supported languages for its CodeQL Bug Bounty program. To celebrate, Ruby submissions will be awarded special bonuses.

The first 10 submissions that score High or Critical could get an additional reward of up to $2,000!

This special bonus program will run for a limited time, for submissions before March 31, 2023.

All for one, one for all (add a new query)

Write a CodeQL query that models a vulnerability class (often linked to a CWE) with high precision (i.e., a low false positive rate) affecting more than one codebase.

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. 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

Generally, any submission that performs poorly on one of our evaluation factors (prevalence, severity, complexity, precision ...) will be rejected. For example, 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 (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). Another example is that queries must be sufficiently general to cover a class of vulnerabilities and may not be tailored to a specific CVE. A third example of rejection is when the query doesn't meet the bar for combination of scope (prevalence in the open source projects) and impact (severity of the vulnerability).

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

The Bug Slayer (disclose and fix vulnerabilities)

Find and disclose multiple vulnerabilities in open source software thanks to a CodeQL query.

How to participate

  1. Select a recent CodeQL query that you authored and that models a vulnerability you’re interested in. This CodeQL query must have been authored by you and proposed via the All For One CodeQL bounty program.
  2. Run your query – or a modified version of it – on real world open source software and find at least four new vulnerabilities of high severity, or two new vulnerabilities of critical severity. The severity is defined in terms of CVSS score. Please note that projects which purposely include a vulnerability pattern for testing purposes, projects that are inactive in the last year, and student, personal or academic projects, are considered out of scope. To assess by yourself if a project is likely to be out of scope, you can compute its criticality score: while it's not a hard criteria, a score less than 0.3 is generally a good indicator that the project is out of scope.
  3. To be eligible for a bounty, you must first coordinate the disclosure and fix of the vulnerabilities with the maintainers of the projects. Report the vulnerabilities to the projects' maintainers, help them fix them, and have them obtain CVEs for each one. For most open source projects, maintainers can easily get a CVE directly from GitHub via Security Advisories.
  4. Important note: We don’t accept CVE for unpatched vulnerabilities. The CVEs must correspond to vulnerabilities that have been disclosed and fixed via coordinated disclosure with the maintainers.
  5. To help you with the disclosure process and the collaboration with the maintainer the Security Lab offers you a vulnerability report template that you can use or inspire from.
  6. Additionally, CVEs published as a result of your research into open source projects may be eligible for a bounty from the Internet Bug Bounty (IBB). To see reporting instructions and IBB Scope, go to the IBB Program page. Even if the project is not in scope, note that the IBB Program is also expanding based on project nominations. We encourage you to reach out with any projects that may not currently be in scope. Nomination instructions can also be found at the IBB Program.
  7. Create an issue using the bug slayer template. The issue should link to your previous All For One submission 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. If you modified the original query, give us the modified version. Please provide any information that proves that your query finds the CVE (for example a LGTM link, a CodeQL DB, a GitHub gist with the modified query).
  8. An award of up to $7,800 USD for multiple critical CVEs will be granted. We consider the severity base score associated with the CVEs and the number of vulnerabilities reported to determine the award. Note that the maximum payout is capped at $7,800 USD corresponding to 8 critical CVEs: if you report more than 8 CVEs, it will not change your final reward.

FAQ – All For One

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. Your submission will be rejected if one of these factors is scored very low.

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 will score too low on one of these factors – for example if they are too simple to meet our minimum complexity requirements or if the scope increment is too small - to be considered eligible. We still welcome these improvements as PRs to the CodeQL repo, but will not consider them for a bounty reward.

What is happening with my submission?

Submissions follow a specific process involving security researchers and CodeQL engineers. A bot (ghsecuritylab) will post updates regarding the submission's status on the submitted issue like the following:

Your submission is now in status <status>.

For information, the evaluation workflow is the following:
Initial triage > Test run > Results analysis > Query review > Final decision > Pay > Closed

The process is made of several deep evaluations of your submission. The team will look at the vulnerability class you are catching, and rate its impact, scope, and prevalence across codebases. On the query side, they will evaluate its precision (FP rate across several codebases), its code quality, performance, etc.

The team will also often give you recommendations to improve your submission, and aim at a higher bounty reward. These recommendations of course take more time, but they are a win-win for you, and for the community who will use your query.

Each submission requires a pair of one security researcher and one CodeQL expert, working together, and often a review from another pair, to ensure fairness and consistency across submissions.

For all these reasons, the response time may vary a lot. Nonetheless, the submission will never be left unattended.

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?

First, keep in mind that (1) you don't need a new CVE, you can use a past CVE if your query detects it, (2) if this is a new vulnerability it must first be disclosed and fixed in coordination with the maintainers. Providing details for an unfixed vulnerability will disqualify your submission.

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 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 a public patch fixing the issue is available. Mention in the issue that a CVE request is in progress and add the CVE later to the issue. Don't add any other detail on the vulnerability.

If your query found vulnerabilities in private source code that you (or your organization) own and therefore you cannot obtain a CVE, reach out to us at `securitylab@github.com` to provide details on the vulnerabilities.

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.

Is your severity assessment strictly equal to the CVE's?

The severity assignment of a CVE looks at the maximum impact, but our assessment considers the most likely impact instead. For example, a query that looks for a vulnerability pattern that may result in serious security issue, but only under special circumstances, could be scored with a lower severity than the submission's CVE.

Can I propose several submissions for the same vulnerability or should I propose all at once?

We recommend to propose all at once. Because if you slice into several submissions – for example for different scopes – you have a risk that some of these submissions will be rejected because of an insufficient prevalence.

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

This can happen when you propose an improvement that just removes some false positive results, in which case the complexity will be minimal, or when you add support for an additional library, in which case the additional scope will be minimal. 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.

FAQ – Bug Slayer

Can I use any already existing CodeQL query?

This program is an extension of the All For One program that gives the query author bonus rewards when their query actually helps in fixing open source vulnerabilities. You can use a query authored by you, submitted via this program.

What if I found vulnerabilities thanks to a CodeQL query authored by someone else?

This program is meant as an extension of the All For One program, and you cannot apply to it with someone else’s query. Feel free to discuss with the original author.

Can I modify the query or must it be the exact original query?

The All For One submissions are usually queries that favor precision – less false positives – over volume. You might want to tweak the query to find more results. If you find real vulnerabilities by tweaking the query, just mention the final query you used in your submission. You can link a gist, for example.

What if I cannot obtain a CVE for these vulnerabilities?

For this program, the CVE requirement is mandatory. 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 use the CVE CVSS score to inform the scoring of your submission and reduce any subjective bias. For most open source projects, maintainers can now get a CVE directly from GitHub via Security Advisories. Additionally, CVEs published as a result of your research into open source projects may be eligible for a bounty from the Internet Bug Bounty. To see reporting instructions and IBB Scope, go to the IBB Program page. Even if the project is not in scope, note that the IBB Program is also expanding based on project nominations. We encourage you to reach out with any projects that may not currently be in scope. Nomination instructions can also be found at the IBB Program.

Can I apply with CVEs that correspond to real issues, but not fixed?

No. The goal of this program is to incentivize the collaboration with maintainers to fix vulnerabilities.

Can I submit my vulnerabilities in several chunks?

The program incentivizes fixing at scale, so the reward scheme favors the submission en-masse rather than by chunks. So yes you can submit in several chunks, but it will always be more interesting to wait and get more CVEs, rather than submitting two by two. If you are concerned by the 6 months deadline, contact us.

How many times can I apply for the bounty with the same query?

See answer above. The reward scheme favors the scale, so it's better for you to submit all CVEs at once. Also note that the reward is capped at $7,800, for a given query.

When can I apply for the IBB?

You can apply when the vulnerability is fixed and the CVE is published. You don’t need to wait for the completion of the corresponding Bug Slayer submission.

Do you accept CVEs that have not been privately disclosed to the maintainer?

No. The goal of this program is to incentivize the collaboration with maintainers to fix vulnerabilities, and our rules state that we accept only CVEs obtained via coordinated disclosure. We'll consider public issues or pull requests only if the maintainer asked or consented to it. We know that private discussion is sometimes difficult but that's precisely why we are offering these rewards. We acknowledge that sometimes, when the maintainer is not responsive, public disclosure is the only option for a researcher, but it's out of scope for this program.

Notes

  1. Coordinated vulnerability disclosure is a vulnerability disclosure model in which a vulnerability or an issue is disclosed to the public only after the vendors or maintainers have been allowed sufficient time to patch or remedy the vulnerability or issue. For example you can read Microsoft's approach to coordinated disclosure.