There has been a lot of chatter on social media lately surrounding the topic of public vulnerability disclosure. Doing a quick Google search, I found a ton of resources, discussions and blog posts available, covering different ways to properly disclose a vulnerability. Several are listed below:


At NTT Security we have a Vulnerability Disclosure Program with policies and procedures concerning responsible vulnerability disclosure. This process has been vetted by our Global Threat Intelligence Center (GTIC) and is followed closely whenever there is a newly identified vulnerability. I have been trained in the process, but hadn’t had the opportunity to submit a vulnerability until this past summer. 

Around the third quarter of 2016, my co-worker and I made a 0-day discovery while performing a penetration assessment for one of our clients. After careful research, we sent our findings to the NTT Security GTIC and eventually submitted the undisclosed vulnerability to the vendor of the software in question. Following our policy, we worked with GTIC to get the vendor everything needed for further investigation. This is the first vulnerability submission that I’ve been a part of, and once we received confirmation from the vendor that it was a valid vulnerability, we were quite excited and couldn’t wait to have our names associated with the discovery. After all, this is a great thing for a security consultant to discover.

This experience, however, has reinforced a couple of lessons I have learned over the years and has taught me why it is a good idea not to publicly disclose a vulnerability until the vendor is ready:

  1. It’s never good to burn bridges in business. This includes relationships with vendors. Unforeseen circumstances delayed the fix, but the vendor is working on it now. Because of their cooperation, I am more than willing to be patient.
  2. This does not (and should not) impact decisions to work with vendors on a public disclosure. Discovering vulnerabilities, and working with the vendor to get a patch in place, will ultimately assist everyone running the vulnerable software.
  3. Who are we helping by disclosing a vulnerability before a fix has been issued? Sure, in some cases there may be other mitigating layers of defense, but I would argue that is really dependent on the situation. Without a fix in place, publicly disclosing the vulnerability could cause more harm than good.

Ultimately it is up to the security researcher or their company to determine when a public disclosure is appropriate. However, here are some considerations before publicly disclosing a vulnerability when the fix has passed your 30, 45, or 90-day disclosure policy:

  1. Have you communicated the vulnerability to the vendor in a professional manner?
  2. Has the vendor been responsive? Has the vendor made an effort to work with you or your team?
  3. Have you seen any evidence that the discovered vulnerability has been exploited in the wild?
  4. How widespread is this vulnerability?
  5. Has the media mentioned this vulnerability?
  6. Will you burn bridges by disclosing this vulnerability before the vendor has a fix?
  7. Is the fix dependent upon a code change or are there other methods for mitigating the vulnerability?
  8. What are the assumptions you’re making about the affected vendor and their product?

Hopefully by thinking through the potential negative impacts of a public disclosure before a fix is in place, we can, as an industry, continue to improve upon this process. Patience and a willingness for vendors and researchers to work with each other will only help to improve public disclosures going forward.