Should the Drupal Association (or someone else central) run a security bug bounty?

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
greggles's picture

A conversation was started on twitter.

I have thoughts on this, but let's get the conversation rolling in a form that allows for more in-depth thoughts than 140 characters ;)

Some topics:

  • Experiences running a bug bounty program (security or otherwise, paid or otherwise i.e. hall of fame counts too).
  • Experiences running a program paying for some work inside a mostly volunteer community
  • What do we hope to achieve with a paid security bug bounty program?
  • Do we think that's a reasonable goal?
  • Are there other models we should use instead or in addition?

Comments

Listening

holly.ross.drupal's picture

Hey all - I have a few questions, but I'll reserve them til later in the discussion. Right now, I just want to say thanks for starting this convo, and note that I am following it. -H

The bounty program around TFA

pwolanin's picture

The bounty program around TFA seems like it was useful since it was very target and time-limited.

I'm not sure how a general bounty program would work for Drupal - is there a risk that we end up competing on price with people trying to buy exploits?

For the sake of argument:

greggles's picture

For the sake of argument: Even if we do end up competing, is that so bad?

Maybe not - I'm sure honest

pwolanin's picture

Maybe not - I'm sure honest people would prefer a bounty that was even 10% of the back-market price.

But could we even offer 10%?

Seems like it's working for

Todd Zebert's picture

Seems like it's working for the likes of Microsoft and Google and many others. Mozilla has one which may be close to our situation: https://www.mozilla.org/security/bug-bounty.html

Seems like we should. Especially if we want to continue to be taken seriously by business and governments. We may have to pay to get bugs out in the open, as the rising tide of for-profit bugs is attempting to keep them secret: http://www.wired.com/2014/09/kevin-mitnick-selling-zero-day-exploits/

It may take some objective, from outside of the community, eyes and thoughts to see our "blind spots".

That's true, but one big

greggles's picture

That's true, but one big difference is that their budgets are worlds beyond ours. When they were our size they didn't have a program.

What other large F/OSS

mpdonadio's picture

What other large F/OSS projects have done this successfully? Do the Google projects count?

I don't think this is a bad idea, but I think there are a few things that may complicate matters.

There may be some issues in the queue that were reported there, and not to the security team, which may be reported later. There is some evidence that this was the case with SA-2014-005. If money is involved, some people may get upset.

There is also the issue of who has the final say about what is a security issue worthy of a bounty. DJB offers bounties on qmail and djbdns. IIRC, there is a bug that some are claiming is an exploit, but the bounty isn't being awarded (I don't follow this closely enough, though, to know the whole story). There are also the issues that get reported to the security team, but get made public. Do these count?

Personally, I think an additional method to bounties would be a more mature post-commit audit process. DrupalCons with organized sprints should have at least one sprint dedicated to just auditing critical components, and not just the current development target.

I also think we need to audit the D7 issue queue for items that need to be brought to the security teams attention.

What other large F/OSS

Matt V.'s picture

What other large F/OSS projects have done this successfully?

Here are a couple of long lists of bug bounty programs:

Keep in mind, some of the listings are "Hall of Fames", which I take to mean that you get your name added to a list of contributors or to the advisories or something similar.

That said, it appears that Mozilla, Chromium Project, Magento, Nginx, OpenSSL, OpenStack, Perl, Phabricator, PHP, Piwik, Python, Ruby, and Ruby on Rails all have reward programs. There are probably more that are open source, but those were ones I'm familiar with.

Personally, I think an additional method to bounties would be a more mature post-commit audit process. DrupalCons with organized sprints should have at least one sprint dedicated to just auditing critical components, and not just the current development target.

I completely agree with the idea of having a more mature post-commit audit process or auditing of the issue queue. However, even something as simple as a Peer Review group here on groups.drupal.org hasn't really gained much traction. Ultimately, someone has to put in a lot of hours to cultivate something like you're describing.

As with anything involving

davidhernandez's picture

As with anything involving money, my first instinct is to ask where does the money come from? Do we assume the DA can even afford to pay out bounties on a regular basis, or do we think they won't be very frequent? Would the DA have to create a new funding program to get people/companies to give specifically to pay out bounties?

Another idea is possibly working this into the d.o profiles. Maybe once we are at the point of fully realizing the user and company profiles, we can have badges/credit for vulnerabilities discovered/fixed. If that system can work in motivating people to contribute code, or anything else, why wouldn't it work for this?

I think this is a great idea,

Bevan's picture

I think this is a great idea, if the DA can afford it. Especially given the DA may need to employ someone to review submissions and recommend payments to winning reports.

In reply to mpdonadio's comment about public reporters being annoyed; I think a bounty programme will raise the awareness of the security team's important work and processes, and encourage people to report properly in order to (maybe) get the bounty. Also; the benefits of having bugs like Drupageddon (SA 2014-05) reported correctly hugely outweigh the disadvantage.

maybe for core, maybe not for contrib

Matt V.'s picture

Right now, the security team issues advisories for both core and contrib modules. A bounty program for contrib has one potential downside that I can envision. Though we do have the community review a user's initial project contribution, once they have access to create full projects there isn't much to stop them from knowingly contributing buggy code. That sets up the possibility of users colluding to collect bounties. The rewards might be too low to make it enticing, but it seemed worth at least bringing up.