The other day I broached the idea of a security bounty in the Drupal project. I had first heard about this concept from the Mozilla Foundation's Security Bug Bounty which appears to be the most famous of these.
Why Security Bug Bounty's are a good idea
This is pretty simple:
- It provides at least some motivation for folks to actually look at the code and find security bugs making the software more secure.
- More folks looking at the code is always a good thing.
- Just the concept and the existence of the program reminds people that we take security seriously, and informs them of the proper way to report a bug.
- In the case of the Drupal Association - which can't make decisions about the code based about the statutes (en pdf) (more formats/languages).
Generalized Security Bug Bounty System
This concept seems to me like it could be generalized for any software project. Here are the rules I came up with, based upon the Mozilla foundation's rules.
- Security bug must be original and previously unreported.
- Security bug must be a remote exploit.
- Security bug is present in the most recent version of the Mozilla Suite, Firefox, and/or Thunderbird, as released by the Mozilla Foundation.
- Security bugs in or caused by additional 3rd-party software (e.g. Java, plugins, extensions) are excluded from the Bug Bounty program.
- Submitter must not be the author of the buggy code nor otherwise involved in its contribution to the project (such as by providing check-in reviews).
- Employees of the project (if applicable) are ineligible.
- If multiple people report the bug the reward will be split among them equally.
- The reporter must follow the stated procedure for reporting bugs to the security team.
- The bug must be critical as determined by the Security team.
Cons of Bug Bounty Systems
Bruce Schneier - who knows a thing or two about security - is lukewarm on the subject of security bug bounties. He in turn cites Moshe Yudkowsky on the topic. Basically their point is - ok, yeah, maybe this is OK but don't expect the bounty to take over for your organizations fundamental need to focus on security internally.
That seems like a no-brainer to me. Obviously we still need to maintain our own internal focus. This just provides an extra motivation for folks, possibly external to the project, to submit their security issue in the proper way.
Wrinkles in the Plan
Depending on your organization, the nitty gritty details (like, having money to do this and being able to send that money to people who may be located far far away) may be complicated. In that case, perhaps alternate solutions would have to be sought out. I'm curious how the Mozilla folks handle payments to places where wire transfers are expensive or where tax code may be complicated.
RFC - Request for Comments
So, what do you think? Yay? Nay? The Drupal Association board will likely take this issue on their agenda in the near future. Your opinion may be valid.