Home » Data Protection » Application Security

Opinion

Bruce Schneier on Disclosure: All or Nothing

Why full disclosure—or the threat of it—forces vendors to patch flaws.

By Bruce Schneier

February 05, 2007 — CSO —

Full disclosure—the practice of making public the details of security vulnerabilities—is a damned good idea. Public scrutiny is the only reliable way to improve security, while secrecy only makes us less secure.

Unfortunately, secrecy sounds like a good idea. Keeping software vulnerabilities secret, the argument goes, keeps them out of the hands of the hackers. The problem, according to this position, is less the vulnerability itself and more the information about the vulnerability.

But that assumes that hackers can't discover vulnerabilities on their own, and that software companies will spend time and money fixing secret vulnerabilities. Both of these assumptions are false. Hackers have proven to be quite adept at discovering secret vulnerabilities, and full disclosure is the only reason vendors routinely patch their systems.

To understand why the second assumption isn't true, you need to understand the underlying economics. To a software company, vulnerabilities are largely an externality. That is, they affect you—the user—much more than they affect the vendor. A smart vendor treats vulnerabilities less as a software problem and more as a PR problem. So if we, the user community, want software vendors to patch vulnerabilities, we need to make the PR problem more acute.

Full disclosure does this. Before full disclosure was the norm, researchers would discover vulnerabilities in software and send details to the software companies—who would ignore them, trusting in the security of secrecy. Some would go so far as to threaten the researchers with legal action if they disclosed the vulnerabilities.

Later on, researchers announced that particular vulnerabilities existed but did not publish details. Software companies would then call the vulnerabilities "theoretical" and deny that they actually existed. Of course, they would still ignore the problems and occasionally threaten the researcher with legal action. Then, of course, some hacker would create an exploit using the vulnerability—and the company would release a really quick patch, apologize profusely and then go on to explain that the whole thing was entirely the fault of the evil, vile hackers.

It wasn't until researchers published complete details of the vulnerabilities that the software companies started fixing them. The software companies hated this. They received bad PR every time a vulnerability was made public, and the only way to get some good PR was to quickly release a patch. For a large company like Microsoft, this was very expensive.

So a bunch of software companies and some security researchers banded together and invented "responsible disclosure" [Editor's note: See "The Chilling Effect"]. The basic idea was that the threat of publishing the vulnerability is almost as good as actually publishing it. A responsible researcher would quietly give the software vendor a head start on patching its software before releasing the vulnerability to the public.