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.

More from Application Security

Kronos Malware Reemerges with Increased Functionality

The Evolution of Kronos Malware The Kronos malware is believed to have originated from the leaked source code of the Zeus malware, which was sold on the Russian underground in 2011. Kronos continued to evolve and a new variant of Kronos emerged in 2014 and was reportedly sold on the darknet for approximately $7,000. Kronos is typically used to download other malware and has historically been used by threat actors to deliver different types of malware to victims. After remaining…

Self-Checkout This Discord C2

This post was made possible through the contributions of James Kainth, Joseph Lozowski, and Philip Pedersen. In November 2022, during an incident investigation involving a self-checkout point-of-sale (POS) system in Europe, IBM Security X-Force identified a novel technique employed by an attacker to introduce a command and control (C2) channel built upon Discord channel messages. Discord is a chat, voice, and video service enabling users to join and create communities associated with their interests. While Discord and its related software…

A View Into Web(View) Attacks in Android

James Kilner contributed to the technical editing of this blog. Nethanella Messer, Segev Fogel, Or Ben Nun and Liran Tiebloom contributed to the blog. Although in the PC realm it is common to see financial malware used in web attacks to commit fraud, in Android-based financial malware this is a new trend. Traditionally, financial malware in Android uses overlay techniques to steal victims’ credentials. In 2022, IBM Security Trusteer researchers discovered a new trend in financial mobile malware that targets…

Twitter is the New Poster Child for Failing at Compliance

All companies have to comply with privacy and security laws. They must also comply with any settlements or edicts imposed by regulatory agencies of the U.S. government. But Twitter now finds itself in a precarious position and appears to be failing to take its compliance obligations seriously. The case is a “teachable moment” for all organizations, public and private. The Musk Factor Technology visionary and Silicon Valley founder and CEO, Elon Musk, bought social network Twitter in October for $44…