Friday, January 29, 2010

Why does the No Free Bugs movement exist?

Having been *a little* bit involved with product development and testing in my time, and being kind of ultra-cognizant of security most of the time, I often wonder about the "No Free Bugs" movement and why it exists.

Why don't companies pay security researchers to find security holes in their products? It seems like a win-win to me.

- By paying the researcher in exchange for signing an NDA (that specifies no disclosure until there's a fix - with a fixed end date, of course!), you get more control over disclosure - less likely to have a pissed off researcher telling everyone about it, plus you've got legal recourse.

- The researcher gets cash, cred, *and* fodder for the security con circuit.

Win-win! Maybe I'm looking at it too simplistically? Is it that researchers don't want to do this? Or corporations don't want to bother? Or don't trust the researchers enough?

External auditing firms are great for CYA, but expensive and still do miss things. Seems to me like augmenting your 'professional' review and internal QA with a few scrappy, bright researchers who are highly motivated to break your security is the ultimate CYA when developing secure products. Each and every layer you can add makes your product stronger and secures yourself against liability.

---
Update - See, Google gets it!

2 comments:

  1. Hi Jen

    Because they don't want to find the bugs in the first place. Finding bugs means additional costs and opportunity costs in developer time--you can't make new features that users want because you're busy doing bug fixes. Features sell product and bring you money, bug fixes do not.

    ReplyDelete
  2. Yeah, you're right! I think, for a lot of companies (especially companies with long-established, complicated products with firmly-entrenched user-bases), it's got to be like going to the dentist for the first time in your late 50s without ever having flossed. If security isn't built-in from the design phase, it's a tangled, expensive mess, and even if it *is* and your developers are well-versed in secure coding practices, it can still be a can of worms no one wants to open. More argument to have a dedicated internal security team - but you're right on that, too, no one wants to spend the money up-front. But oooh, how much it costs to continually patch...

    ReplyDelete