Why bug bounties aren't a cure for broken software

Microsoft joins other vendors in rewarding those who privately report software vulnerabilities -- but that may not reduce customer risk

Page 2 of 2

Software vendors would love nothing more than to pay the most money for bugs that, if not patched, would cause the most amount of pain for customers. But vendors and exploit finders have no way of knowing whether a particular bug will go nuclear. In my more than two decades of experience, I've become aware of a few bugs each year that I knew could go nuclear -- but didn't. Conversely, the bugs that do go big often aren't all that new or interesting. Many have even had patches available for a long time.

You might think that patching a bigger number of security exploits would directly reduce security risks for customers. This is not true. For example, Microsoft software (I work for Microsoft) has had far lower numbers of known exploits than any of its nearest competitors -- including Apple, Google, and Red Hat -- for a long time now, but Microsoft software is still among the most exploited products. This is mostly due to the fact that it's the most popular software.

There's a patch for that
More to the point, 99 percent of all successful client computer exploitations do not involve unpatched vulnerabilities. They involve vulnerabilities that are known and for which patches are available -- just unapplied. Or they don't involve a code vulnerability at all, such as socially engineered Trojans, phishing, and so on.

It could even be argued that a bug bounty program, because it results in a larger number of known exploits and patches, could actually result in more exploited customers, not fewer. I know this goes against conventional wisdom, but if you look at the methods by which most users are successfully exploited, I can't come to any other conclusion.

If found vulnerabilities could be addressed with more consistent patching, then we might have something. Actually, Microsoft does fairly well in this area, as its software consistently ranks among the most promptly patched software in the cyber ecosystem. Google often patches its software in hours to days after a bug is reported. The problem is that a certain percentage of users don't patch their software in a timely manner -- and certain categories of software tend to be badly patched. Of course, if you don't apply publicly available patches, you can't really fault the vendor.

Plus, a large percentage of client exploits involve inducing users to install something they shouldn't (such as fake antivirus programs or other bogus applications). Bug bounty programs don't affect these sorts of attacks, and aren't meant to.

The return on bug bounties
In theory bug bounty programs should result in decreased risk for a vendor's customers, but the ultimate measure of success is whether that vendor's customers are actually attacked successfully less often over time. Realistically, this is almost impossible to isolate for.

Even customers of a company with a good bug bounty program may suffer at the hands of one new bug that was not submitted through the program -- or one that customers failed to patch in a timely manner. One bug can cause a whole lot of problems. A vendor can report that it closed more security holes than ever and still have more of its customers hacked than ever in the same year.

Don't get me wrong. I'm fairly excited about vendor bug bounty programs, especially because they give white hat hackers a way to earn money for their talents legally. But I'm still waiting for definitive results that say they actually result in fewer exploited customers.

This story, "Why bug bounties aren't a cure for broken software," was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes' Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

| 1 2 Page 2
From CIO: 8 Free Online Courses to Grow Your Tech Skills
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies