Patch Reward Program Rules
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, Omaha, 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, Tink
- The reference implementation of Certificate Transparency and its open-source dependencies
- Toolchain security improvements for GCC, binutils, and llvm
- Security-relevant bits of common package managers: yum, apt, pip, npm
- Popular web frameworks and libraries: Angular, Closure, Dart, Django, Dojo Foundation, Ember, GWT, Go, Jinja (Werkzeug, Flask), jQuery, Knockout, Polymer, Struts, Web2py, Wicket
- Popular CMS platforms: WordPress, Joomla, Drupal, Magento, PrestaShop, OpenCart, Typo3
- Widespread decompression libraries: zlib, bzip2, tar, gzip, info-zip, cpio, xz, 7z, p7zip, ncompress, lzo
- Critical software used for cloud computing: Envoy proxy
- Projects integrated into OSS-Fuzz
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 or sandboxing,
- Memory allocator hardening,
- Cleanups of integer arithmetics,
- Systematic fixes for various types of race conditions,
- Elimination of error-prone design patterns or library calls,
- Contextual auto escaping in templates.
- Changes to support nonce-based Content Security Policy adoption in web applications (details).
- Refactorings that make it easier to reason about the security properties of the code.
- Projects integrated with OSS-Fuzz that are critical to user and internet security (details).
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 without reverts for one month. After these prerequisites are met, please submit via our form here.
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 has been accepted without reverts for one month 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 $20,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:
- Up to $20,000 for ideal integration with OSS-Fuzz defined here.
- $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 double your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
Rewarding research papers
Security research is not just about attacks. Rather, it also involves analyzing and arguing for the absence of attacks or for the soundness of designs, through, for example, formal verification methods or as done in provable security for cryptographic algorithms and protocols. We value such work, and reward research papers which can prove that a construction, protocol, or implementation is secure, or which introduce new concepts or theory on how to make things more secure.
An example of a paper that was rewarded in the past:
Please submit your paper for consideration here. The paper should satisfy the following requirements:
- The paper covers one of the topics listed in the “Projects in scope” section above.
- The paper should be publicly available through an online repository such as eprint or arxiv.
- Any IP contained in the paper should be released to the public domain.
Although not required, publication in a well-regarded journal or presenting at a well-known conference is encouraged. Our reward philosophy for research papers is the same as for patch reward submissions. See the “Reward amounts” section above.
Frequently asked questions
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, Kees Cook, Ivan Fratric, Eduardo Vela Nava, Peter Valchev, Natalie Silvanovich, Josh Armour, and Aleksandr Dobkin.
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.