Full or Responsible Disclosure: How Security Vulnerabilities Are Disclosed

Matthew Hughes 15-09-2015

Three weeks ago, a serious security issue in OS X 10.10.4 was discovered. That, in itself, isn’t particularly interesting.


Security vulnerabilities in popular software packages are discovered all the time, and OS X is no exception. The Open Source Vulnerability Database (OSVDB) shows at least 1100 vulnerabilities tagged as “OS X”. But what is interesting is the way in which this particular vulnerability was disclosed.


Rather than tell Apple and give them time to remedy the problem, the researcher decided to post his exploit on the Internet for everyone to see.

The end result was an arms-race between Apple and black-hat hackers. Apple had to release a patch before the vulnerability was weaponized, and the hackers had to create an exploit before the at-risk systems get patched.

You might think that particular method of disclosure is irresponsible. You could even call it unethical, or reckless. But it’s more complicated than that. Welcome to the strange, confusing world of vulnerability disclosure.


Full vs Responsible Disclosure

There are two popular ways of disclosing vulnerabilities to software vendors.

The first is called full disclosure. Much like in the previous example, researchers immediately publish their vulnerability into the wild, giving the vendors absolutely no opportunity to release a fix.

The second is called responsible disclosure, or staggered disclosure. This is where the researcher contacts the vendor before the vulnerability is released.

Both parties then agree on a time frame where the researcher promises not to publish the vulnerability, in order to give the vendor an opportunity to build and release a fix. This time period can be anywhere from 30 days to a year, depending on the severity and complexity of the vulnerability. Some security holes cannot be fixed easily, and require entire software systems to be rebuilt from scratch.


Once both parties are satisfied with the fix that’s been produced, the vulnerability is then disclosed and given a CVE number. These uniquely identify each vulnerability, and the vulnerability is archived online on the OSVDB.


But what happens if the waiting time expires? Well, one of two things. The vendor will then negotiate an extension with the researcher. But if the researcher is unhappy with how the vendor has responded or behaved, or they feel the request for an extension is unreasonable, they might simply publish it online with no fix ready.

In the security field, there are heated debates as to what method of disclosure is best. Some think that the only ethical and accurate method is full disclosure. Some think that it’s best to give vendors an opportunity to fix a problem before releasing it into the wild.


As it turns out, there are some compelling arguments for both sides.

The Arguments In Favor Of Responsible Disclosure

Let’s look at an example of where it was best to use responsible disclosure.

When we talk about critical infrastructure within the context of the Internet, it’s hard to avoid talking about the DNS protocol How To Change Your DNS Servers & Improve Internet Security Imagine this - you wake up one beautiful morning, pour yourself a cup of coffee, and then sit down at your computer to get started with your work for the day. Before you actually get... Read More . This is what allows us to translate human-readable web addresses (like into IP addresses.

The DNS system is incredibly complicated, and not just on a technical level. There’s a lot of trust placed in this system. We trust that when we type in a web address, we’re sent to the right place. There’s simply a lot riding on the integrity of this system.



If someone was able to interfere with, or compromise a DNS request, there is a lot of potential for damage. For example, they could send people to fraudulent online banking pages, thereby allowing them to obtain their online banking details. They could intercept their email and online traffic through a man-in-the-middle attack, and read the contents. They could fundamentally undermine the security of the Internet as a whole. Scary stuff.

Dan Kaminsky is a well respected security researcher, with a long resume of finding vulnerabilities in well-known software. But he’s most well known for 2008’s discovery of perhaps the most severe vulnerability in the DNS system ever found. This would have allowed someone to easily perform a cache poisoning (or DNS spoofing) attack on a DNS name server. The more technical details of this vulnerability were explained at the 2008 Def Con conference.

Kaminsky, acutely aware of the consequences of releasing such a severe flaw, decided to disclose it to the vendors of the DNS software that are affected by this bug.

There were a number of major DNS products affected, including those built by Alcatel-Lucent, BlueCoat Technologies, Apple and Cisco. The issue also affected a number of DNS implementations that shipped with some popular Linux/BSD distributions, including those for Debian, Arch, Gentoo and FreeBSD.

Kaminsky gave them 150 days to produce a fix, and worked with them in secret to help them understand the vulnerability. He knew that this issue was so severe, and the potential damages so great, that it would have been incredibly reckless to publicly release it without giving the vendors an opportunity to issue a patch.

Incidentally, the vulnerability was leaked by accident by security firm Matsano in a blog post. The article was taken down, but it was mirrored, and one day after publication an exploit This Is How They Hack You: The Murky World of Exploit Kits Scammers can use software suites to exploit vulnerabilities and create malware. But what are these exploit kits? Where do they come from? And how can they be stopped? Read More had been created.

Kaminsky’s DNS vulnerability ultimately sums up the crux of the argument in favor of responsible, staggered disclosure. Some vulnerabilities – like zero day vulnerabilities What Is a Zero Day Vulnerability? [MakeUseOf Explains] Read More – are so significant, that to publicly release them would cause significant damage.

But there’s also a compelling argument in favor of not giving advance warning.

The Case For Full Disclosure

By releasing a vulnerability into the open, you unlock a pandora’s box where unsavory individuals are able to rapidly and easily produce exploits, and compromise vulnerable systems. So, why would someone choose to do that?

There are a couple of reasons. Firstly, vendors are often quite slow to respond to security notifications. By effectively forcing their hand by releasing a vulnerability into the wild, they’re more motivated to respond quickly. Even worse, some are inclined to not publicize Why Companies Keeping Breaches a Secret Could be a Good Thing With so much information online, we all worry about potential security breaches. But these breaches could be kept secret in the USA in order to protect you. It sounds crazy, so what's going on? Read More the fact they were shipping vulnerable software. Full disclosure forces them to be honest with their customers.

But it also allows consumers to make an informed choice as to whether they want to continue to use a particular, vulnerable piece of software. I would imagine the majority would not.

What Do Vendors Want?

Vendors really dislike full disclosure.

After all, it’s incredibly bad PR for them, and it puts their customers at risk. They’ve tried to incentivize people to disclose vulnerabilities responsibly though bug bounty programs. These have been remarkably successful, with Google paying $1.3 million dollars in 2014 alone.

Although it’s worth pointing out that some companies – like Oracle Oracle Wants You To Stop Sending Them Bugs - Here's Why That's Crazy Oracle is in hot water over a misguided blog post by security chief, Mary Davidson. This demonstration of how Oracle's security philosophy departs from the mainstream wasn't received well in the security community... Read More – discourage people from performing security research on their software.

But there are still going to be people who insist on using full disclosure, either for philosophical reasons, or for their own amusement. No bug bounty program, no matter how generous, can counter that.

Related topics: Computer Security, Hacking.

Affiliate Disclosure: By buying the products we recommend, you help keep the site alive. Read more.

Whatsapp Pinterest

Leave a Reply

Your email address will not be published. Required fields are marked *

  1. Anonymous
    September 16, 2015 at 1:39 am

    "After all, it’s incredibly bad PR for them, and it puts their customers at risk. "
    OTOH, not disclosing vulnerabilities and getting caught at it is GOOD publicity. Or, as is the case with Oracle, discouraging security research. Also, not disclosing vulnerabilities and/or discouraging security research does not put customers at risk???

    Oracle is a prime example of what happens when "responsible disclosure" is made to an irresponsible company.