Google Open Source Software Vulnerability Reward Program recognizes the contributions of security researchers who invest there.
time and effort in helping us secure open source software released by Google (Google OSS).
Through this program, we provide monetary rewards and public recognition to researchers who disclose vulnerabilities in Google OSS to us.
Repositories in scope
The program covers all the latest versions of open source software stored in the public repositories of Google-owned GitHub organizations and selected repositories hosted on other platforms.
The program also covers repository configuration settings (e.g. GitHub actions, access control rules, GitHub application configurations).
Third-party dependencies
A critical element of the security of a software package is the security of its dependencies, so vulnerabilities in 3rd-party dependencies are in scope for this program.
That said, please send your bug reports directly to the owner of the vulnerable package first and ensure that the issue is addressed upstream before letting us know of the issue details.
Just like we would like to learn about vulnerabilities in our code first, we feel 3rd-party code authors should have the same advantage.
Submissions detailing vulnerabilities through 3rd-party dependencies should:
Demonstrate that the vulnerability manifests itself in our projects (i.e. you must show that the 3rd-party vulnerability can be triggered or exploited in Google OSS).
Be shared no earlier than 30 days after the issue was fixed upstream (e.g. a patched software package was released).
Vulnerabilities in 3rd-party services or platforms used to maintain and build Google OSS (e.g. source code management systems, CI/CD systems, package managers) are out of scope for this program. We cannot authorize you to conduct security research of assets that belong to other users and companies on their behalf.
Google Open Source
That said, we welcome submissions describing vulnerabilities in our configuration or integration of those 3rd-party services.
Qualifying Vulnerabilities
Supply chain compromises
First and foremost, we welcome submissions pointing out vulnerabilities affecting source or build integrity that could result in a supply chain compromise.
Supply chain vulnerabilities include the ability to compromise Google OSS source code, and build artifacts or packages distributed via package managers to users. For example:
Ability to modify or submit code on main branches of repositories
Vulnerabilities in the configuration of build and release infrastructure that lead to the compromise of artifacts that are distributed to users, e.g.:
Vulnerabilities in Google OSS GitHub Actions configuration
Insecure configuration of a project’s GCP build environment setup
Disclosure of package manager credentials for publishing build artifacts
Compromise of cryptographic signing keys for published artifacts
Product vulnerabilities
Any design or implementation issue in Google OSS that causes a product vulnerability substantially affecting the confidentiality or integrity of user data in software builds using Google OSS is also in scope for the program. Some examples:
1.Memory corruption issues in file format parsers or network protocol implementations
2.Failures in the sanitizer functions (e.g. HTML sanitizers)
3.Path traversal issues
4.Bad defaults or insecure code examples in project documentation.
Other security issues
We would also like to know about issues that affect the security of the target projects, but don’t map to the above categories as they are not technical security vulnerabilities. For example:
1.Sensitive credentials that give write access which have been stored in personal projects (e.g. dotfiles)
2.Credential leaks in publicly stored backups
3.Weak passwords for 3rd-party CI systems for which we don’t control the password policy
4.Insecure installation / software usage instructions that compromise the security of the developers working on the product
There are a couple of classes of vulnerabilities that generally do not qualify for a reward:
1.Security vulnerabilities and weaknesses with a root cause in downstream software integration with Google OSS (e.g. insecure configuration of Google OSS libraries, or third-party code calling Google OSS functions documented to accept sanitized inputs, with non-sanitized inputs).
2.Typosquatting / dependency confusion, unless it can be demonstrated how this leads to a compromise of Google OSS build artifacts distributed to users.
3.Issues with negligible security impact, as described in the Bug Hunter University.
Out of concern for the availability of our services to all users, please do not attempt to carry out DoS attacks, leverage black hat SEO techniques, spam people, or perform other similarly questionable actions.
Whenever possible, please try to test the vulnerabilities locally without impacting other users. We also discourage the use of any vulnerability testing tools that automatically generate significant volumes of traffic.
Project tiers
Project tiers indicate the sensitivity and criticality connected with projects, and have implications for the reward amounts the VRP grants to researchers.
Flagship OSS projects
This tier contains selected Google open source projects that we consider particularly sensitive. Rewards for vulnerabilities found in projects in this tier are significantly higher than for projects in other tiers.
-Bazel
-Angular
-Golang
-Protocol buffers
-Fuchsia
-Note: In the future, we plan to add more projects to the flagship tier.
Standard OSS projects
his tier contains all software repositories that are not explicitly mentioned in the criteria of other tiers. Typically, they fulfill all of the below requirements:
1.Repository is active and open to receive commits (i.e. not labeled as archived, deprecated, or in maintenance mode).
2.Repository stores code of a software library, framework, or end-user product.
3.Build artifacts from the repository are published in one of the popular package manager registries (e.g. npm, PyPI).
4.Released packages are marked as stable, release candidate, or late beta.
Since this tier contains a large number of vastly different projects, rewards for vulnerabilities in this tier can vary depending on the relative importance of the project.
Low-priority OSS projects
This tier contains small, experimental, sample, and other low-priority projects. Projects in this tier typically have some combination of the following properties:
1.Non-existent or small community impact
2.No active development
3.Marked as “experimental”, “sample”, “not an official Google product”
4.No executable code in the project (e.g. projects serving
documentation websites)
5.Projects accompanying research projects conducted by Googlers
6.Repository belongs to “google-research”, “googleinterns”,
“googlearchived”, or similar GitHub orgs
7.No CI/CD setup on the repository
We currently do not financially reward submissions describing issues in projects from this tier.
Reward amounts
The following table outlines typical rewards for the most common classes of bugs, depending on the affected project tier.
The final amount is always chosen at the discretion of the reward panel.
In particular, we may decide to pay higher rewards for unusually clever or severe vulnerabilities;
decide to pay lower rewards for vulnerabilities that hinge on the existence of other, not-yet-discovered or hypothetical bugs to become exploitable,
require unusual user interaction or other rarely-met prerequisites; decide that a single report actually constitutes multiple bugs; or that multiple reports are so closely related that they only warrant a single reward.
For every reported vulnerability, the security impact is evaluated by looking at the most dangerous attack scenario that the panel can come up with. If we discover higher-impact attack vectors that the original reporter hadn’t considered in the submitted report, we bump up the score accordingly.
When receiving multiple reports, we typically only reward once per root cause and group similar vulnerabilities together. We might also give small bonus increases of around $1,000 USD for particularly clever or interesting vulnerabilities.
We offer the option to donate your reward to an established charity. If you do so, we will double your donation – subject to our discretion. Any rewards that remain unclaimed after 12 months will be donated to a charity of our choosing.
We also encourage you to check out our Patch Rewards program, which offers rewards for making security improvements to Google’s open source projects (e.g. up to $20K for fuzzing integrations in OSS-Fuzz).
Reporting bugs
All bugs should be reported using the vulnerability form (in the Bug Location step, specify the repository URL and select the affected product. If you can’t find the product in the list, select “Google OSS”).
We ask you to submit high-quality reports, including as many details as possible, a buildable proof of concept against a recent build, a crash dump if available, and instructions on reproducing the issue. Please also include information about the affected software version, a description of the issue’s impact, and an attack scenario, as that helps us assess the vulnerability quickly and effectively.
For tips on improving your reports, also refer to the Bug Hunter University.
Legal points
We are unable to issue rewards to individuals who are on sanctions lists, or who reside in countries (e.g., Cuba, Iran, North Korea, Syria, Crimea, and the so-called Donetsk People’s Republic and Luhansk People’s Republic) on sanctions lists.
You are responsible for any tax implications depending on your country of residency and citizenship. There may be additional restrictions on your ability to enter the program depending upon your local laws.
This is not a competition, but rather an experimental and discretionary rewards program. You should understand that we can cancel the program at any time and the decision as to whether or not to pay a reward has to be entirely at our discretion.
Your testing must not violate any law, or disrupt or compromise any data that is not your own.
To avoid potential conflicts of interest, we will not grant rewards to people employed by Google or Google Partner companies who develop software covered by this program.
