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:

Qualifying submissions

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:

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.

Reward amounts

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:

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:

  1. The paper covers one of the topics listed in the “Projects in scope” section above.
  2. The paper should be publicly available through an online repository such as eprint or arxiv.
  3. 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 qualify?
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 submission privately?
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.

Legal points

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.