Back to top

RFC - Security Bounties in Open Source

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:

  1. It provides at least some motivation for folks to actually look at the code and find security bugs making the software more secure.
  2. More folks looking at the code is always a good thing.
  3. 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.
  4. 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.

People Involved: 
timeline: 

Comments

Interesting

Interesting concept. Various thoughts off the top of my head, in no special order.

1) What counts as an "employee"? The 5 core committers (Dries, Steven, Gerhard, Neil, Gabor)? Members of the Association? Someone who writes more than X amount of code (for some vague definition of X)? Anyone who's ever submitted a patch to core?

2) How big a bounty? Naturally it should be large enough that we attract a fair number of security grad students who want practice, but not so high that we end up bankrupting the Association. :-)

3) Bruce is, as usual, right. But yes, there's no reason we can't do both.

4) Presumably the bounty is collected only after the bug has been fixed and a new release made?

Overall I am not opposed to the idea.

some answers

1) In the case of Drupal, there are no employees, so this is easy :) I was generalizing from the Mozilla rules and trying to make the rules simple enough for any project.

2) I believe the association has to decide this. If it were up to me - it would be no less than $100. If we had a specific fundraising event for it, perhaps we could do more.

3) Exactly :)

4) I think that's reasonable. Part of the goal is to make sure that people follow through on keeping quiet until the release is done, so yeah, no bounty until it's released.

I think it's a great idea

There are not many ways the Drupal Association can distribute funds without causing strife, or at least angst. This way I feel is not one of them. Why? Because (at least the way I understand it) the bounty comes out of the same do-ocracy that drives the community as a whole. If you do some security patch, then you get something for it.

I wouldn't advocate this for any kind of new module or functionality, but we all benefit from improved security, and finding little ways to incentivise the creativity and insight of a greater community -- even when our existing security team is doing such an avesome job -- to improve Drupal's overal security I feel is a good thing.

If it works for Mozilla, and if the D.A. has the geld, maybe it's something to try?

OTOH, if the general sentiment is more in line with Larry's, then I wouldn't suggest moving forward. I wouldn't want to advocate anything that might upset the positive dynamic within the Drupal community. Perceptions are important.

Well, in this case the

Well, in this case the bounty goes to the reporter - who probably isn't the person who creates the patch to fix it. Security bugs are generally easier to fix than to find. Also, the "person" that makes the patch is generally a collaborative effort of the security team. So I think this is a reasonable solution to give the bounty to the reporter.

I agree that money can be a tough thing to introduce into Open Source projects, but I think that in this case it's not like these are full time employees but just one off situations which, in my opinion, limits the potential for a negative impact.

Nice!

I think this is a great idea. Although, I still believe that we need to educate the community more about writing secure modules. Security bounties are good to push the elimination of critical bugs but if we get developers to think security the first time they start developing their modules we are better off! From previous conversations I have had with Drupal developers. I get the impression most "drupalers" do not really care much about security, because they do not really understand the significance of the subject. Some developers believe they do not need to worry about security because they do not have an "eCommerce" website or do not host restricted information.

This is why I started last DrupalCon Europe with a short intro on using tools such as webscarab to audit Drupal modules. I wanted to present a more organized presentation this year at Yahoo but the community lacked interest. I believe the reason is because they do not know any better. Therefore, we need to keep educating the community specially newcomers.

When you get a chance take a look at this article from Bruce Schneier

http://news.com.com/Schneier+questions+need+for+security+industry/2100-7355_3-6179500.html?part=rss&tag=6179500&subj=news

great minds think alike

Well, Rasmus spent most of his time at OSCMS2007 talking about security, so at least you are in good company by focusing on that :)

The other article you linked is good. Security is really important which is why I see this as one way to "shine a light" on security and it's importance to the project.

paranoia = survival

I agree. And I am really glad about your initiative! Please let me know how I could aid your efforts. I am willing to contribute financially as well.

I should mention that one way I tried to help, which was similar to your effort was to use OWASP spring of code and Google summer of code as way to start more interest in improving Drupal's security. You may want to check OWASP and see if there is still time to submit something although I doubt it. I passed the information and contacts to Heine but I think he was not able to submit anything due to lack of time perhaps?

The only drawbacks I see...

The only drawbacks I see is that this will inevitably cause more security releases. And so anyone who has not installed via CVS (i.e. the people who are only doing one website with Drupal) are going to be doing a lot more work upgrading their sites. This is bound to cause some hard feelings.

Also from an external perspective, a long list of reported exploits can look like inherent flaws in the system (ex. Joomla has 6 exploits reported this year, Drupal has 10). We know that Drupal is in fact inherently more secure, but others won't.

10 or 3?

As Jeff Eaton has explained - there have actually not been nearly that many advisories about Drupal core. Secunia counts 1 in Drupal5 and 2 in 4.7. I think we're doing pretty well on just the numbers.

The really important thing is that none of these are "zero day" exploits - that they are not known about until the security team releases the patch. So, the security team can wait and bundle them all together into a monthly or quarterly release that contains several fixes all together.

About long lists of exploits - you can interpret that lots of ways. Hopefully this would make Drupal developers focus more on security reducing the number of exploits that get introduced in the future.

Add new comment