Bug Bounties Are Not Security

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.

Tags: , ,

Posted on December 27, 2005 at 7:46 AM • 20 Comments

Comments

aikimark • December 27, 2005 8:36 AM

The delivery analogy reminds me of the bozo sort, where random items in the list are swapped until the list is sorted (if ever).

This blog might start an interesting discussion of Test-Driven Development (TDD), automated testing, white-room development, QA department relationship with the development staff (should be distant, code coverage, and other related topics. This should prove interesting.

I would think that part of the QA functions might be suitable for off-shoring in an attempt to throw as many fingers at the application as possible. But throwing QA solely to the market does seem like a recipe for disaster.

EiffelTower • December 27, 2005 10:01 AM

I’ll take the bait.

Test-Driven Development (TDD)

is not about finding errors, it’s about “driving”/leading your design/development. The quality/content of the testing can be anywhere from “intuitive testing” (which is not even good for experienced programmers, but exceptionally bad for below-average programmers) to /insertfavouritetestingmethod/.

Using TDD will not (practically) make your software have less bugs.
Now if you were using fully fledged assertions [including pre-/post-conditions for every aspect] (which can be interpreted as a more “complete” way of TDD) you’re talking Betrand Meyer.

J.D. Abolins • December 27, 2005 10:35 AM

The bug bounty concept is useful as long as it not made a significant component of the security process or encourage reducing other measures.

One big problem is that not everyone who finds a bug is going to want to cash in on the bounty. If the bug is exploitable and one wants to use the bug for criminal purposes, one might hope the bug remains in the production version. Even if one isn’t going to exploit the bug, collecting the bounty puts one on the radar as somebody tinker about and looking for bugs. May be a good thing or a bad thing.

Milan Ilnyckyj • December 27, 2005 11:27 AM

I wonder how sensitive the kind of people who look for bugs would be to this kind of inducement. If they have been doing it so far without financial encouragement, it implies that the appeal lies elsewhere – perhaps in simple curiosity or the desire for publicity.

It’s certainly possible that offering financial incentives would bring new entrants into the field, however.

aikimark • December 27, 2005 11:33 AM

I think the contest must ensure that there are lots of folks hammering away at the application. Also, you need a particularly sophisticated method for tracking what part of the code the bug finders have covered and the data they’ve entered. You should award first, second, and third place prizes. Testers should register ahead of time and should receive some reward (or potential for reward/random prize) for just for signing up to be a tester, such as a t-shirt or other geeky swag.

There should be known bugs left in the code and all discussions and bugs should be published in an open forum. Be prepared to sacrifice modules in existing versions to be sure you are ready to expose your beta code to this process.

It would also be wise to establish a multi-national set of teams to compete for country-specific awards. (Russia, China, India, Japan, Brazil, EU, USA)

Jeremy Bowers • December 27, 2005 12:06 PM

“I think the contest must ensure that there are lots of folks hammering away at the application.”

No, it doesn’t. I’ve yet to see a contest that makes it worthwhile for me, an experienced developer who likes finding security holes, to enter. Even if you absolutely guaranteed $100 a bug, regardless of whether anybody else finds it first, there’s still too much uncertainty about what I’ll find and what the company will consider a “bug” worthy of payout for me to spend any significant time on it. And…

“You should award first, second, and third place prizes.”

If you constrain it such that only three people will get prizes, now I’m completely uninterested, since that drops the expected payout of any work I do well below the point where I should just do something else.

All this will get are college students with nothing better to do and insufficient skill to obtain access to the ability to make much better and more reliable money out of their time, as I can. (That is to say, yes, there are some good college students, but they often manage to get paid, too.)

“There should be known bugs left in the code and all discussions and bugs should be published in an open forum.”

And that, of course, defeats the entire purpose. If you want to play games, fine, but those games have even less relevance to real security than a contest on the real code.

You’re not addressing the real problem. The problem isn’t that contests provide no incentive in absolute terms, the problem is that the opportunity cost of participation is too high, thus providing negative incentive in the ways that matter. By the time the contest pays out enough for it to be worthwhile for a skillful person to participate, it’s more worthwhile for the company just to hire them for less money than they’d payout. Thus, contests are never a cost effective way to find bugs.

And of course, that’s not the real reason for them. Marketing, marketing, marketing. And the point of posts like this is to try to educate people so this sort of deceptive marketing doesn’t fool anyone.

David Harmon • December 27, 2005 12:12 PM

Accepting bug findings from “the public” is really just good sense, in that there will always be some such activity, and “you don’t have all the smart people”. Having decided to do that, it’s not entirely unreasonable to encourage people to report problems.

Also, you’d much rather those folks submit their bugs swiftly, but with all relevant information, and “due diligence” on their part. One simple way to get all that is to offer money, to the first person who submits a “proper” report for a given bug.

That said, the scheme is still a supplement, rather than a replacement, for your own QA efforts. “Outsiders” will often spot stuff your own people wouldn’t, but if your guys don’t narrow the field, you’ll spend all your time sorting bug reports for stuff you could (should) have spotted and fixed yourself.

Woo • December 27, 2005 1:56 PM

If nothing else, at least it ensures that the company will listen to bug reports. That’s already a large step better than several other large software companies.
Personally, I’d not necessary need a reward for reporting bugs, it’d already be enough if reported bugs would be confirmed and, preferably, fixed in near future.

jammit • December 27, 2005 2:13 PM

Fantastic! I’ll make a mint from MS alone!!!
Offering a bug bounty won’t cause bugs to be turned in at a greater rate, although giving a reward for a bug you fixed sounds like a good idea. My favorite idea is the trackback or MS error reporting tool. When a program crashes it phones home with the error.

Koray Can • December 27, 2005 2:53 PM

I think that those who find bugs on their own time should be awarded for their efforts. This should even be encouraged. However, this has so little value that it’s not even worth talking about.
The practice is an admission of not being able to secure one’s products. Ideally, it should be so hard for an individual (with his limited time and resources) to find a security hole that most researchers should not bother with it no matter how high the prize. Until then, this just tells that the boat is covered with holes, and it makes sense financially to go after some of them as an outsider. And not all of them will be found.
By the way, the awards are not sky high, either. If it’s that cheap to find a security hole, why doesn’t company X do it in-house? Do security researchers suddenly become incompetent once they’re on the payroll?

Tom Lord • December 27, 2005 2:58 PM

What do you think about the trends in the open source world towards, on the one hand, offering bounties for newly contributed source code that is certain to be under-reviewed and, on the other hand, offering bounties for testing and bug fixes?

Good game design, guys!

-t

radiantmatrix • December 27, 2005 3:28 PM

@EiffelTower:
“Using TDD will not (practically) make your software have less bugs.”

That’s not really true. When I moved to TDD, I saw the number of bugs introduced into code fall drastically. TDD, when done correctly, causes you to write tests before writing code, and then write the minimum code needed to make that test pass without breaking previous tests. This helps you spot many very common classes of bugs long before they even get committed to the repository.

The two things TDD rhetoric often seems to promise but does not deliver are bug-free code and a reduction in security flaws.

Tests are still code, so badly-written tests or conditions that weren’t tested (edge cases, etc.) due to oversight will still result in bugs. TDD does, however, make those easier to find and fix.

Security flaws aren’t always “bugs” in code in the classical sense, but often design decisions or problems with underlying technology. TDD doesn’t address this, and so security in design is not repaired or enhanced by TDD.

Moz • December 27, 2005 4:16 PM

One problem is the size of the reward. What’s a day zero exploit worth on the open market these days? The bounty is effectively competing with that, so you’ve just created another player in what is already an active auction market.

The other sort of bugs in the vein of “it doesn’t work” could easily be dealt with by a combination of intensive logging and reporting home. All you need to do is convince users that it’s worth having slow, bulky apps in return for…. just a second, isn’t that the Microsoft way?

Jeff Olhoeft • December 28, 2005 9:54 AM

As a previous poster mentioned, any bounty is going to be too small to motivate someone to go looking for bugs. I think the principal value in this is to encourage customers who find bugs to report them, and in a fairly complete manner. I know that I often will encounter a bug, kick on the software until I can figure out a work around, and move on to the next thing without mentioning it to the vendor. After messing with the bug, I rarely am in the mood to try and fill out a bug report and explain everything I was doing. In a sense the bounty is not for finding the bug, but going to the trouble to explain it to the vendor.

Ari Heikkinen • December 28, 2005 8:33 PM

“Cash rewards for freelance researchers is a cheap and easy way to fix security holes. But critics say the expanding practice could hurt the software security industry.”

I didn’t quite get that one. Maybe they mean security people like Bruce are hurting from it or something? Still don’t get it.

Ari Heikkinen • December 28, 2005 8:37 PM

Just to add, I think the idea of delivering software modules is debug them and run them thru some test suites with asserts on spots that could go wrong. That would already catch most bug if they know anything about what they’re trying to do do.

Moz • December 29, 2005 10:22 PM

One thing that some companies are doing that hurts them is charging people to report bugs. If VMware has issues it generates a dump file and so on, then asks you to submit it. Doing so requires you to purchasea $US35 “support incident”. I guess VMware don’t want to know about any problems…

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.