GitHub Security Lab
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.
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.
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 experimental folder. 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 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.
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.
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.
Find and disclose multiple vulnerabilities in open source software thanks to a CodeQL query.
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.
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 or academic projects, are considered out of scope.
To be eligible for a bounty, you must first coordinate 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.
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.
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.
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.
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).
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.
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.
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. Your submission will be rejected if one of these factors is scored very low.
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.
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.
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.
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 responsible disclosure policy.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
No. The goal of this program is to incentivize the collaboration with maintainers to fix vulnerabilities.
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.
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.
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.
This policy crawled by Onyphe on the 2020-07-21 is sorted as bounty.
FireBounty © 2015-2024
