Slashdot Mirror

← Back to Stories (view on slashdot.org)

Are Bug Bounties the Right Solution For Improving Security?

Posted by timothy on from the 10-bucks-says-they-might-be dept.

saccade.com writes Coding Horror's Jeff Atwood is questioning if the current practice of paying researchers bounties for the software vulnerabilities they find is really improving over-all security. He notes how the Heartbleed bug serves as a counter example to "Linus's Law" that "Given enough eyeballs, all bugs are shallow." "...If you want to find bugs in your code, in your website, in your app, you do it the old fashioned way: by paying for them. You buy the eyeballs. While I applaud any effort to make things more secure, and I completely agree that security is a battle we should be fighting on multiple fronts, both commercial and non-commercial, I am uneasy about some aspects of paying for bugs becoming the new normal. What are we incentivizing, exactly?

13 of 58 comments (clear)

  1. You buy eyeballs and loyalty. by vidarlo · · Score: 5, Insightful

    NSA is buying security holes to use against us. This is part of what Snowden revealed with the leaks.

    Offering a bounty, even though it is not as much as the security problem could fetch on the grey market, creates a certain loyalty towards the vendor, and makes it easier to go to them, and ensure the hole gets patched. It also attracts more eyeballs to your software, as finding a problem means money. Google has gone even further - by offering grants for research into specific products, where you get money for checking security of the software, not just finding security prolems.

    So I believe it is a good thing; it probably means more holes will be reported directly to the vendor, and not sold for exploit. It probably attracts eyeballs as well...

    --
    Assembling etherkillers for fun an profit
  2. The problem is by Rosco+P.+Coltrane · · Score: 3, Funny

    It pays better to exploit the bugs...

    --
    "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
    1. Re:The problem is by Opportunist · · Score: 2

      Depends on whether you're able to actually monetize it. Exploiting a bug doesn't make money come out of your computer.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  3. Enough eyeballs and heartbleed ... by QuietLagoon · · Score: 5, Interesting

    ... He notes how the Heartbleed bug serves as a counter example to "Linus's Law" that "Given enough eyeballs, all bugs are shallow."...

    I think the big issue with the Heartbleed bug was that the OpenSSL code base was so egregiously poorly written and maintained that eyeballs started bleeding whenever they looked at it. imo, the OpenSSL code base never had enough eyeballs looking at it to make its bugs shallow. It was painful to look at, so eyeballs avoided looking at it.

    .
    I still think that Linus' Law hold true, or at least is a very good guideline. I think exceptions like the OpenSSL code base are needed to hone the point that Linus' Law makes.

    I also take issue with the headline, as I do not think there is any one right solution for improving security. The improvement of security is a multi-faceted endeavour and an ongoing process.

    1. Re:Enough eyeballs and heartbleed ... by Rosco+P.+Coltrane · · Score: 4, Insightful

      I think the only thing the OpenSSL bug shows is how flimsy the underlying framework of the internet is. Most of the shit we all use, trust and take for granted was coded in someone's basement over the weekend a long time ago. All it takes is one clever guys to take a good look at the code to exploit it, and it's probably fair to say he'll be the only one to review the code ever...

      --
      "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
    2. Re:Enough eyeballs and heartbleed ... by OzPeter · · Score: 3, Interesting

      I think the big issue with the Heartbleed bug was that the OpenSSL code base was so egregiously poorly written and maintained that eyeballs started bleeding whenever they looked at it. imo, the OpenSSL code base never had enough eyeballs looking at it to make its bugs shallow. It was painful to look at, so eyeballs avoided looking at it.

      I agree. Heatbleed is not a counter example, it is simply evidence that the original "Linus's Law" was not complete. A better version of it would be

      Given enough eyeball hours, all bugs are shallow

      With the definition of "enough" being dependent on the complexity of the code in question.

      --
      I am Slashdot. Are you Slashdot as well?
    3. Re:Enough eyeballs and heartbleed ... by jones_supa · · Score: 2

      I think the big issue with the Heartbleed bug was that the OpenSSL code base was so egregiously poorly written and maintained that eyeballs started bleeding whenever they looked at it. imo, the OpenSSL code base never had enough eyeballs looking at it to make its bugs shallow. It was painful to look at, so eyeballs avoided looking at it.

      That's really just speculation.

      So let's everyone ask ourselves this question: how many times do we personally browse open source code, looking for vulnerabilities or other bugs?

      Let me guess that the answer is: I mostly run precompiled binaries, and might rarely take look at a particular small piece of code to solve a specific problem (which I came across by running the binary).

      I suggest that it just is likely that most OSS projects are like OpenSSL: only the core developers take a look at the codebase.

      My solution is that instead of relying on Linus's Law, we should be more thinking about dedicated professional code audits, because those actually work and can be really powerful in improving security. Big commercial shops like Microsoft and Apple already do this in spades internally as part of their QA procedures.

    4. Re:Enough eyeballs and heartbleed ... by QuietLagoon · · Score: 2

      ...So let's everyone ask ourselves this question: how many times do we personally browse open source code...

      "Everyone" does not need to do it. You've set up a premise that fails on face value.

    5. Re:Enough eyeballs and heartbleed ... by Bite+The+Pillow · · Score: 2

      A better version of Linus' Law would be the original one.

      So, if rapid releases and leveraging the Internet medium to the hilt were not accidents but integral parts of Linus's engineering-genius insight into the minimum-effort path, what was he maximizing? What was he cranking out of the machinery?

      Put that way, the question answers itself. Linus was keeping his hacker/users constantly stimulated and rewardedâ"stimulated by the prospect of having an ego-satisfying piece of the action, rewarded by the sight of constant (even daily) improvement in their work.

      Linus was directly aiming to maximize the number of person-hours thrown at debugging and development, even at the possible cost of instability in the code and user-base burnout if any serious bug proved intractable. Linus was behaving as though he believed something like this:

              8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

      Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's Law''.

      My original formulation was that every problem ``will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, ``and somebody else understands it. And I'll go on record as saying that finding it is the bigger challenge.'' That correction is important; we'll see how in the next section, when we examine the practice of debugging in more detail. But the key point is that both parts of the process (finding and fixing) tend to happen rapidly.

      http://www.catb.org/~esr/writi...

  4. start at the root, we must have securable hardware by anwyn · · Score: 3, Insightful
    Free software, yes. Bug bounties, maybe.

    But recent developments have made clear that securable hardware is sine qua non. All firmware must be in socketed memory, so that you can take it out and externally check it. You can't trust an untrusted system to check itself. All firmware must be protectable with a hardware readonly jumper or switch.

    I know that this is inconvenient and a revolution on how hardware is currently made. but if people started demanding it en mass, it would not cost very much. And I mean the firmware in disk drives and optical media players and especially routers.

    There may be other requirements.

    This is sine qua non. Without this we have nothing.

  5. Re:start at the root, we must have securable hardw by jones_supa · · Score: 2

    What I personally think is really scary is that a lot of devices in our PCs are ready to accept new firmware at any moment. There usually are no safeguards that I can enable to prevent malicious code being injected to core components like BIOS, CPU microcode, HDD, DVD...

    Now, in general, hardware security is a tricky concept, because currently the hardware layer is simply fully trusted.

  6. it scales by slashmydots · · Score: 2

    Any expense that scales with the job it does or problems it solves is a good thing. Why pay someone XX per hour to sort books in a book store if you can pay them $0.05 per book and ensure static, scaled costs that tie to inventory cycling (aka sales) directly. Then again, you don't know how many bugs are in your program.

  7. The downside... by xlsior · · Score: 3, Funny

    ...was covered almost 20 years ago by Scott Adams: http://dilbert.com/strip/1995-...