From Heartbleed to Shellshock and Poodle to Backoff, this has been a banner year for software vulnerabilities. Despite their appearance on myriad devices across a host of industries and operating systems, these threats share a common thread: They’ve all been disclosed to the public. The ensuing security fallout has some experts wondering whether a responsible disclosure policy is really a safeguard or just another siren song for cybercriminals.

Define ‘Responsible’

So what exactly is a responsible disclosure policy? Simply put, it is the release of details surrounding IT security vulnerabilities after a certain amount of time has passed. How much time depends on who has the information and how serious the potential threat is.

For example, the Community Emergency Response Team (CERT) Division of the Software Engineering Institute’s policy is to disclose any vulnerability data it receives 45 days after the initial report has been filed, but it will make allowances for “threats of an especially serious nature.” CERT argues that while 45 days puts pressure on organizations to fix identified vulnerabilities, this is not an impossible timeline.

What’s more, there are cases where the specter of eventual disclosure can motivate companies to patch exploits or design better code. Other agencies offer a 90-day window, while others offer no window at all, preferring “open disclosures” where any bug or vulnerability is released to the public immediately.

The bottom line? There is a lot of room to move on the issue of what is “responsible” and no general agreement on the ideal release schedule.

The Security Problem

Which is the better course, releasing details immediately, or holding data long enough for companies to close up security holes? A responsible disclosure policy tends to take the ethical high ground. It is often seen as a way to keep amateur bug hunters from blackmailing large companies into paying for silence and to keep high-profile bugs behind doors until fixes can be found.

For example, Heartbleed was discovered around March 21, according to The Age, but it was released to the public on April 7, prompting a firestorm of criticism about how the threat was handled, even though a patch had been developed. There have also been rumors that software companies unhappy with early disclosures have sought out IT professionals and had them fired or otherwise inconvenienced for damaging the brand’s good name. Ideally, responsible disclosures balance the need for freedom and privacy by providing enough time to correct issues while still keeping the public informed.

Unlocked Doors?

As noted by Wired, however, there is another argument against this kind of disclosure. Telling malicious actors which pieces of code are vulnerable is like giving robbers keys to the bank vault. The twist? These robbers never needed keys in the first place. Any cybercriminal determined to punch through network defenses has already learned about potential vulnerabilities and won’t be surprised by anything a disclosure report has to say. Keeping this information quiet only serves to spur on criminal acts, since very few IT security professionals even know what’s happening, let alone how to correct the problem.

Taking the argument further, Wired references an Alfred Charles Hobbs book, “The Construction of Locks,” published in 1853. In it, Hobbs argues that discussing the insecurity of locks does nothing to encourage crime by “rogues” since they “are very keen in their profession and know already much more than we can teach them respecting their several kinds of roguery.” Replace “roguery” with “hacking” and locks with software, and the book is spot-on. Malicious actors aren’t waiting with bated breath for the next security disclosure — they’re already two steps ahead.

Collaborative Effort

The real sticking point for IT security is collaboration. A responsible disclosure gives companies time to fix software problems, but many don’t reach out to other agencies for help, preferring to keep code in-house and solve problems in isolation. In a world where large-scale cyberthreats and zero-day vulnerabilities are happening month after month to network after network, however, this kind of head-in-the-sand thinking simply no longer works. Scheduled disclosures provide a reasonable, ethical framework for tackling vulnerabilities, and working together shortens the time required.