...

• What information should be provided about the vulnerability?
• Where should this information be provided?
• What, if any, additional measures should be taken to draw attention to the existence of the vulnerability or the availability of its fix?

Prepare and Circulate a Draft

...

An example of a template for a vulnerability disclosure document is provided in the appendices.

When to Engage a Coordinator

In multiparty CVD, private notifications to other vendors and even public disclosures by individual vendors may not sufficiently raise awareness or accurately reflect the scope of a vulnerability. Because of the role they play in conveying information to a broad audience of system deployers, trusted third parties (non-vendors) such as DHS CISA, the CERT/CC, or other coordinators can help notify affected vendors, facilitate technical analysis of the vulnerability and its impact, and amplify communications to the public.  When vendors provide advance notice of major vulnerabilities to the coordinator community, it allows the various coordinating organizations to prepare accurate remediation instructions for system deployers, and to publish that information in synchronization with the vendors’ release of the patches. When that advance notification does not occur sufficiently early, as in the case of Meltdown and Spectre[5], coordinators may be in a rush to understand the issue while preparing their advisories, leading to erroneous or inadequate advice to their constituencies.

Publishing

Once the draft circulation phase is complete, the next step is publishing the vulnerability document to whatever channels have been identified during previous phases.

Some vendors have a specific website that lists all their security advisories to date. Others might email the disclosure to a user mailing list or a security mailing list such as Full Disclosure [2] or BugTraq [1]. Reporters themselves may also chose to disclose by posting the advisory to a mailing list or including it in a personal or company blog. A common goal for reporters in the CVD process is to synchronize their publication with the vendor's response. As a result, near-simultaneous publication occurs quite often.

It is generally courteous for the vendor and reporter to contact each other after disclosure to inform one another that the disclosure went through as planned and provide URLs to the published documents.

...

However, even with a well-organized customer contact database, it can be difficult for a vendor to be certain that all relevant decision makers are reached in a timely manner. Hence, we recommend that vendors publish at least basic vulnerability and fix announcements to their public website in addition to whatever direct customer contact communications they provide.

References

1. Security Focus, "BugTraq Archive," [Online]. Available: http://www.securityfocus.com/archive/1. [Accessed 23 May 2017].
2. Seclists.org, "Full Disclosure Mailing List," [Online]. Available: http://seclists.org/fulldisclosure/. [Accessed 23 May 2017].
3. MITRE, "Common Vulnerabilities and Exposures," [Online]. Available: https://cve.mitre.org/. [Accessed 16 May 2017].
4. MITRE, "Common Vulnerabilities and Exposures (CVE) Numbering Authority (CNA) Rules Version 1.1," 16 September 2016. [Online]. Available: https://cve.mitre.org/cve/cna/CNA_Rules_v1.1.pdf. [Accessed 16 May 2017].
5. Sharwood, Simon. "Intel didn't tell CERTS, govs, about Meltdown and Spectre because they couldn't help fix it." 23 February 2018. https://www.theregister.co.uk/2018/02/23/meltdown_spectre_letters_to_congress/