The purpose of bug bounties

| TrackBacks (1) |
Bruce Schneier writes:
Paying people rewards for finding security flaws is not the same as hiring your own analysts and testers. It's a reasonable addition to a software security program, but no substitute.

I've said this before, but Moshe Yudkowsky said it better:

Here's an outsourcing idea: get rid of your fleet of delivery trucks, toss your packages out into the street, and offer a reward to anyone who successfully delivers a package. Sound like a good idea, or a recipe for disaster?

Red Herring offers an article about the bounties that some software companies offer for bugs. That is, if you're an independent researcher and you find a bug in their software, some companies will offer you a cash bonus when you report the bug.

As the article notes, "in a free market everything has value," and therefore information that a bug exists should logically result in some sort of market. However, I think it's misleading to call this practice "outsourcing" of security, any more than calling the practice of tossing packages into the street a "delivery service." Paying someone to tell you about a bug may or may not be a good business practice, but that practice alone certainly does not constitute a complete security policy.

While I agree that bug bounties shouldn't be one's sole method of providing software security, I think this analogy kind of misses the point. As I see it, the objective of a bug bounty system isn't to find vulnerabilities: it's to control their distribution by incentivizing researchers to bring them to you first rather than just publishing them. Remember that a vendor's proximal security incentive isn't to minimize the number of security vulnerabilities in their software but rather to minimize the amount of exposure that customers experience due to unfixed vulnerabilities that are known to bad actors.

There are two basic strategies that a vendor can follow to effect this goal. First, they can invest effort in reducing the number of vulnerabilities in their software, thus making it harder for anyone to find vulnerabilities and presumably reducing the number found by bad actors. The second strategy is to try to keep vulnerabilities out of the hands of bad actors after they're discovered. This is where bug bounties come in. They provide an incentive for non-malicious researchers to come to the vendor first rather than publishing first (this is obviously important if it takes you a long time to develop a fix) and if they're high enough they might even persuade someone who was otherwise malicious to sell you their vulnerabilities rather than exploiting them.

I think what's underlying Bruce and Moshe's objections is that if all you do is pay bounties then your software still has a large number of vulnerabiliites in it just waiting to be discovered by someone who doesn't want to take your bounty. That's certainly true, and it feels yucky to have all that stuff in there, but this objection sort of tacitly assumes that that's somehow not the case (or at least significantly less so) if you do hire your own analysts and testers. It's not clear that that's so at the levels of investment that organizations are typically willing to put in.

1 TrackBacks

Listed below are links to blogs that reference this entry: The purpose of bug bounties.

TrackBack URL for this entry:

bad credit personal loans from bad credit personal loans on January 19, 2006 3:10 PM

heaver scraps Rio prouder.weakly?syndicate credit Read More