Source: Michele Wright, Product Manager

I have been part of several conversations recently and the topic of “responsible disclosure” seems to be coming up more and more. There are strong opinions around who needs what information at what time. There are many perspectives you can take on this topic.

  1. I am the customer. I need to know what is going on in my product.
    a. An offshoot of #1: My Regulatory Agency says so, which means you HAVE to tell me
  2. I am the vendor. It’s my product and I don’t want to tell customers everything before I’m ready.
  3. I am an evil hacker. Please tell me everything. I’m waaaaiting…

By just looking at the different stakeholders on this topic, there are a range of perspectives and each one comes with its own risks. It is certainly justifiable for a customer to want, er, demand, that they are entitled to full and reasonable disclosure. However, if a vendor provides notification of every potential vulnerability the minute they discover it, they are opening customers and the greater community up to even more risk. Even if the vendor just notifies customers directly, there is still a risk of this information getting into the hands of bad actors. For some, “ignorance is bliss” – meaning that if you don’t know, the vendor can work to provide the fix (patch) simultaneously with the vulnerability notification. At this point, the customer can be aware and protect themselves quickly and efficiently. If all things were ideal, this could work out to be a reasonable approach. Yet, the story doesn’t end here.

In many cases, installing the patches is one of the strongest mitigation tactics available. However, that critical step is not always taking place. According to a 2018 study by Ponemon, “57% of respondents who reported a breach said that they were breached due to a vulnerability for which a patch was available but not applied. 34% say they actually knew they were vulnerable before the breach occurred.” (
There is a recent example where an undisclosed power company was compromised, even though the mitigating patch was available.

The Denial of Service event took advantage of a known software vulnerability that required a previously published patch to fix, according to the DOE official.

In other words, with a patch in hand, it wouldn’t have been difficult for power companies to identify and update any computer systems potentially at risk. (

There are a variety of reasons why installation of the patches can be restrictive: time, resources, knowledge, prioritization, and security and criticality assessments. The list is long. However, risk is risk. While I’m a strong advocate of vendors making their customers aware and culpable of identified vulnerabilities, there is an equal, if not stronger, commitment on the part of the customer to have a plan in place to mitigate these vulnerabilities – whether through having a strong patching program or other compensating controls in place. As a wise man once said, “Knowing is only half the battle” – GI Joe.

Additional information available here:

Want to Read More?
A case study in how “responsible” disclosure can go wrong
Guidance on how to handle vulnerability disclosure: ISO/IEC 29147:2018 and ISO/IEC 30111:2013

FoxGuard provides a wide range of patch management solutions that help entities identify and mitigate gaps in the security of their systems and prepare for security audits. We host a webinar series to discuss ways to develop and implement a robust patch management program. Reserve your spot in our next session.


If you want to discuss something specific, we will do that too! Just reach out, tell us what your challenges are, and we will have one of our security experts contact you.