Page History

...

• Should you disclose at all? – Generally, the answer will be yes, but there may be factors that influence this decision. For example, some vulnerabilities, if exploited, could place lives in danger or cause severe socioeconomic harm. As a result, it may be prudent for reports of such vulnerabilities to be held indefinitely until the population of vulnerable systems has been reduced through patching or obsolescence. However, any decision to defer disclosure should be considered provisional or contingent on the continued absence of evidence of exploitation or adversarial knowledge of the vulnerability.
• What information will you disclose? – For example, will you publish all information about the vulnerability, including proof of concept code, or will you only release a brief description of the problem and a remediation? Generally speaking, there is a minimum amount of information required in order for a vulnerability report to be useful. Recall that the point of disclosure is to provoke some action, most often by deployers or any downstream vendors who were not already involved in the coordination process. If the details provided to the recipient are insufficient to cause that action to be taken, the disclosure process will not succeed.
• To whom will you disclose? – In most cases, the disclosure should be made publicly. However, in some scenarios the disclosure may be to a specific limited group. For example, if the pool of users is small and the vendor reaches out to every impacted user, a public disclosure may be unnecessary.

• Via what channel(s) will you disclose? – Will the vulnerability information be published on the vendor's website? The reporter's blog? BugTraq [1], Full Disclosure [2], or other mailing lists? Will you draw attention to it on social media? There are pros and cons to most of these options that must be weighed. When available, an organization's communications or public relations groups should be involved in planning for the disclosure process. While it is usually neither possible nor practical to have every CVD case flow through them, leveraging their expertise in planning and developing the CVD capability can improve the process considerably.

• What is your expectation of others in disclosing further (or not)? – Be sure to discuss your expectations with all stakeholders and be prepared to negotiate.
  
  

Vendors in particular will need to address three main questions in providing vulnerability and fix information to defenders:

...

Publicly disclosing the existence of a vulnerability and the availability of its fix is usually considered to be the primary goal of the CVD process.

Vendors will often provide vulnerability information:

• on On the vendor's public website. Many vendors offer a security-focused section within the support section of their online offerings.
• to To a public mailing list or a vendor-specific list
  
  

Vendors of bespoke software or products with highly focused customer bases are sometimes reasonably confident that they can reach their affected users directly. 

These vendors often publish vulnerability and fix information:

• on On a customer-only site
• via Via a customer support mailing list
• by By individually notifying customers, for example through the technical sales channel

...