No matter who you are, most of the smartest people work for someone else.
– Bill Joy, Sun Microsystems

Anyone who becomes aware of a vulnerability that does not appear to have been remediated should report the vulnerability to the vendor. One should not assume that a vendor is aware of a specific vulnerability unless it has already been publicly reported, whether by the vendor or elsewhere. The easier it is to report vulnerabilities to a vendor, the less likely that the vendor will be surprised by vulnerability reports disclosed directly to the public.

Advice for Reporters

Finding Vendor Contacts

Making initial contact with a vendor can sometimes be more difficult than it should be. Here is a list of techniques we've used to figure out how to reach a vendor we've never spoken with before.

Common Methods

Less common, but occasionally useful

We have rarely had to resort to these techniques, but they have been occasionally useful.

When all that fails

Some vendors remain unreachable even after a number of reasonable good faith attempts to reach them—and by reasonable we mean considerably less than exhausting the entire list above. Some vendors just do not seem to want to be reached, and that is their prerogative. However, we have found that experience is often the best teacher. When a vendor gets surprised by the publication of a vulnerability in their product and it is clear from the report that attempts to notify them were made but failed, it can prompt the vendor to re-evaluate their vulnerability intake and handling processes to make it easier to reach them in the future.

Providing Useful Information

Reporting a vulnerability requires that the vulnerability is well-documented. This typically means providing the following information:

Reporters that do not provide enough information to a vendor or coordinator may find their reports delayed or even rejected. Using CWE [3] or CAPEC [4] as a reference might be helpful to describe the type of vulnerability you have found and common ways to fix it the problem.

An example of a template for a vulnerability report, based on the CERT/CC's own Vulnerability Reporting Form (VRF) [5], is provided in Appendix D. Vendors that require additional information to validate reports should clearly document their specific requirements in their vulnerability disclosure policy, reporting form, or process description.

Advice for Vendors

Vendors need a mechanism to receive vulnerability reports from others. This reporting mechanism should be easy enough to use that it encourages rather than discourages reports. It can be as simple as a dedicated email address for reporting security issues, a secure web form, or a bug bounty program. Aside from the technical aspects of encouraging reporting, vendors can also provide reporters with other incentives, as discussed in Section 2.4.

Create Secure Channels for Reporting

Whether you are a vendor or a coordinator, you need to have open channels for communication with vulnerability finders and reporters. In our experience, the most common means of communication is email. For this reason, the CERT/CC recommends that vendors establish a specific and well-publicized email alias such as <> solely for receipt of vulnerability reports.

However, since email is an insecure communications channel by default, many vendors, reporters, and coordinators prefer to use encrypted mail instead. Although x.509 encrypted mail exists, we have found PGP-compatible tools such as GnuPG to be more widely used by CVD participants. Vendors are encouraged to create and publish a PGP key affiliated with the security email alias to allow the confidentiality of sensitive reports to be maintained in transit. 

Alternatively, some vendors choose to offer a web form specifically for receiving reports of security-related issues. Such forms can then deliver the report directly to your security or engineering team. The CERT/CC discourages reliance on general "Contact Us" web forms that pass through an organization's communications or customer support teams. Many finders will balk at having to get past these nontechnical interfaces into the vendor. In addition, security messages often must be triaged and processed differently than other incoming contacts.

Another possibility is to make use of a third-party bug bounty or coordination platform. For more information on common CVD tools, see Section 7.

Reduce Friction in the Reporting Process

As a vendor, it is important to not treat reporters with suspicion or hostility. It's likely they have important information about your product, and they want to share it with you.
Furthermore, vendors should take care not to frustrate reporters' attempts to make contact by building too many assumptions into their CVD process.

In the course of our own vulnerability coordination efforts, we have observed all of the following erroneous assumptions built into vendor's CVD process:


  1. Wassermann, Garrett. Reach Out and Mail Someone. 6 August 2015.
  2. K. Price, "Writing a bug report - Attack Scenario and Impact are key!" 2 August 2015. [Online]. Available: [Accessed 17 May 2017].
  3. MITRE, "Common Weakness Enumeration (CWE)," [Online]. Available: [Accessed 17 May 2017].
  4. MITRE, "Common Attack Pattern Enumeration and Classification," [Online]. Available: [Accessed 17 May 2017].
  5. CERT/CC, "Vulnerability Reporting Form," [Online]. Available: [Accessed 17 May 2017].

< 4.1 Discovery | 4.3 Validation and Triage >