On October 9, 2013, we announced a new, experimental program that rewards proactive security improvements to select open-source projects. This effort complements and extends our long-running vulnerability reward programs for Google web applications and for Google Chrome.
Projects in scope
We intend to roll out the program gradually, monitoring the quality of the received submissions and the feedback from the developer community. Currently, the scope is limited to the following projects:
- Open-source foundations of Chrome and Android: Chromium, Blink, AOSP
- Security-critical, commonly used components of the Linux kernel (including KVM)
- High-profile web and mail servers: Apache httpd, lighttpd, nginx, Sendmail, Postfix, Exim, Dovecot
- Other high-impact network services: OpenSSH, OpenVPN, BIND, ISC DHCP, University of Delaware NTPD
- Core infrastructure data parsers: libjpeg, libjpeg-turbo, libpng, giflib, zlib, libxml2
- Other essential libraries: OpenSSL, Mozilla NSS
- Toolchain security improvements for GCC, binutils, and llvm
Any patch that has a demonstrable, significant, and proactive impact on the security of one of the in-scope projects will be considered for a reward. Examples include:
- Improvements to privilege separation,
- Memory allocator hardening,
- Cleanups of integer arithmetics,
- Systematic fixes for various types of race conditions,
- Elimination of error-prone design patterns or library calls.
Reactive patches that merely address a single vulnerability may qualify, but will be reviewed on a case-by-case basis.
Making submissions to the program
In order to qualify, your patch must first be submitted directly to the maintainers of the project, and you must work with them to have it accepted into the repository and incorporated into a shipping version of the program. After these prerequisites are met, please submit your entry to firstname.lastname@example.org.
We ask you to respect the time of your fellow volunteers, and strictly adhere to the coding, testing, and submission standards employed for each project. For the reasons explained in the FAQ, submissions made before the patch is approved and shipping will not be considered for rewards.
When notifying us, please include links to all the relevant code locations and diffs. Be sure to explain the project-specific benefits offered by the patch.
Rewards for qualifying submissions range from $500 to $10,000. The final amount is always chosen at the discretion of the reward panel and is based on our judgment of the complexity and impact of the patch. The usual reward amounts are:
- $10,000 for complicated, high-impact improvements that almost certainly prevent major vulnerabilities in the affected code.
- $5,000 for moderately complex patches that offer compelling security benefits.
- $1,337 for submissions of modest complexity, or for ones that offer fairly speculative gains.
- $500 "one-liner special" for trivial improvements that nevertheless have a merit from the security standpoint.
We may choose higher rewards for unusually clever or complex submissions; we may also split the reward between the submitter and the maintainers of the project in cases where the patch required a substantial additional effort on behalf of the development team.
We offer the option to donate rewards to charity. If you make this choice, we will match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
Frequently asked questions
Q: Why does my patch need to ship in order to qualify for a reward?
A: There are two reasons for this. Firstly, we want to minimize the burden on the maintainers of the projects by making it worthwhile to submit higher-quality, production grade code. Secondly, it’s a matter of follow-through: a patch that never ships simply doesn’t help much :-)
Q: The maintainers don’t want my patch. Can you help me with this?
A: No. It is up to the maintainers to decide whether to accept a proposed patch. Given the nature of the program, we do not wish to second-guess the decisions of those managing the project.
Q: I’m a core developer working on one of the in-scope projects. Do my own patches
A: Most certainly!
Q: Why there is so little emphasis on fixing individual bugs?
A: In short, we decided to try something new. Quite a few vulnerabilities trace back to preventable coding mistakes, or are made easier to exploit due to the absence of simple mitigation techniques. We are hoping to address this to some extent.
Q: Who determines whether my report is eligible for a reward?
A: The reward panel consists of the members of the Google Security Team with a knack for researching low-level bugs. The current members are Abhishek Arya, Chris Evans, Ivan Fratric, Ben Hawkes, Tavis Ormandy, Peter Valchev, Tim Willis, and Michal Zalewski.
Q: My employer / boyfriend / dog frowns upon my security research. Can I make a
A: Sure. If you are selected as a recipient of a reward, and if you accept, we will need your contact details to process the payment. You can request not to be listed on our public credits page.
We are unable to issue rewards to individuals who are on sanctions lists, or who are in countries (e.g. Cuba, Iran, North Korea, Sudan and Syria) 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 depending upon your local law.
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.
Of course, you need to make sure that your work does not violate any law and does not disrupt or compromise any data that is not your own.