CVE Numbering Authorities

Participating CNAs

The organizations below are participating as CVE Numbering Authorities (CNAs) as of September 2009:

Primary CNA

Software Vendors

  • Apple (Apple issues only)
  • Adobe Systems Incorporated (Adobe issues only)
  • Hewlett-Packard (H-P issues only)
  • Oracle (Oracle issues only)
  • Cisco Systems, Inc. (Cisco issues only)
  • Red Hat, Inc. (Linux issues only)
  • Debian GNU/Linux (Linux issues only)
  • FreeBSD (primarily FreeBSD issues only)
  • Ubuntu Linux (Linux issues only)
  • Microsoft Corporation (Microsoft issues only)
  • Silicon Graphics, Inc. (SGI issues only)

Third-Party Coordinators

  • CERT/CC

Researchers

  • Secunia

Introduction to Candidate Reservation

Candidate reservation allows responsible researchers, vendors, and incident response teams to include candidate numbers (i.e., CVE names with "candidate" status) in the initial public announcement of a vulnerability. It ensures that a candidate number is instantly available to all CVE users and makes it easier to track vulnerabilities over time.

The basic process is:

(1) There is a request for one or more candidate number(s).

(2) MITRE reserves the candidate number(s) and provides the number(s) to the requester, and creates "blank," content-free candidate(s) on the CVE Web site.

(3) The requester shares the candidate number(s) with all parties involved in the disclosure.

(4) The requester includes the candidate number(s) in the vulnerability advisory.

(5) The requester makes the candidate(s) public and notifies MITRE.

(6) MITRE updates the candidate(s) on the CVE Web site to provide the details.

(7) MITRE proposes the candidate(s) to the CVE Editorial Board.

(8) If a candidate is accepted as an official CVE entry, then the requester updates the number in the advisory.

If a candidate was reserved and the issue was never made public, the candidate will be deleted. Since the candidate was never public—and in some cases, the candidate was never assigned to a specific vulnerability—the number is deleted entirely.

Role and Requirements of CNAs

CNAs are organizations that distribute CVE candidate numbers to researchers and information technology vendors for inclusion in first-time public announcements of new vulnerabilities, without directly involving MITRE in the details of the specific vulnerabilities. On an as-needed basis, MITRE provides a CNA with a pool of candidate numbers for the CNA to assign.

CNAs can help the CVE Initiative in several ways. When they function as intermediaries between a vulnerability researcher and the affected vendor, they can provide a candidate number without notifying MITRE of the vulnerability, which reduces the risk of accidental disclosure of vulnerability information. They increase the scope and visibility of CVE candidates by providing additional access points for researchers and vendors to obtain candidate numbers. They can utilize existing working relationships with researchers and vendors, which the affected parties may not have formed with MITRE. If they are already an integral part of the normal process by which vulnerabilities are disclosed, their participation prevents the addition of another party (i.e., MITRE) from interfering with that process or causing further delays. Finally, their participation relieves MITRE of some potentially labor-intensive tasks, allowing it to dedicate resources to other aspects of CVE that need attention.

Requirements for Being a CNA

A CNA must be a major software vendor with a significant user base and an established security advisory capability, or an established third party that typically acts as a neutral interface between researchers and vendors. MITRE also functions as a CNA in a limited capacity.

The CNA must be an established distribution point for first-time vulnerability announcements. It must have a member of the CVE Editorial Board who performs technical tasks. In keeping with the CVE requirement to identify public issues, the CNA must only assign candidates to security issues that will be made public. Finally, it must follow responsible disclosure practices that are accepted by a significant portion of the security community. Responsible disclosure is important for CVE because otherwise, it is more likely that duplicate or inaccurate information will be introduced into CVE.

CNA Tasks

CNAs must consistently apply documented CVE content decisions (with exceptions made for technical subtleties or incomplete documentation). They must also coordinate the exchange of candidate numbers across all involved parties (vendor, researcher, response team, etc.) in order to reduce the risk of producing duplicate candidate numbers. CNAs must notify MITRE when candidates have been publicly announced. Since disclosure practices directly impact the accuracy of CVE, CNAs must recommend best practices in vulnerability disclosure to both researcher and vendor. A CNA must verify that the reported vulnerability has not already been assigned a CVE or candidate number.

MITRE is working to increase the number of CNAs. Some of the greatest challenges are educating CNAs about content decisions and determining the process for exchanging candidate numbers across multiple parties, especially if more than one party reserves candidates from MITRE.

Communications from CNAs to MITRE

The following series of communications occur between CNAs to MITRE:

(1) The CNA requests a pool of candidate numbers.

(2) The CNA announces the publication of a new candidate, which allows MITRE to update the candidate information on the CVE Web site.

(3) The CNA may need to consult with MITRE regarding CVE content decisions.

(4) The CNA notifies MITRE of suspected abuses of the CVE process by researchers.

(5) The CNA notifies MITRE and other parties when duplicate candidates are detected.

The primary method of communication is through email, although telephone discussions are sometimes necessary when a problem is particularly complex with respect to CVE content decisions or the nature of the vulnerability.

A third-party CNA must also maintain awareness of all vendors and CNAs who utilize candidate numbers. Since a third party might gain a competitive advantage by initially providing candidate numbers to a limited audience (outside of the researcher and vendor), the CNA should not publish CVE candidate numbers in any manner which might provide it with an economic, technical, or political advantage over its competitors.

A vendor CNA must clearly advertise their security point of contact. They must provide the candidate to other affected parties, e.g., other vendors, researchers, or response teams. They must include candidate numbers in their own advisories. They can only use their pool of candidates for vulnerabilities in their own products. They must apply CVE content decisions to determine the proper number of candidates to assign, even if the content decisions are contrary to the vendor’s own criteria. If the issue does not meet the vendor’s minimum risk level for releasing an advisory, the CNA should still provide candidates for that issue. Finally, when an issue has already been published and assigned a candidate, the vendor must use the existing candidate number.

corner corner
Accidental Assignment of Duplicate Identifiers

When duplicate CVE identifiers are accidentally assigned by vendors, researchers, or coordinators and made public in initial public vulnerability announcements, CVE’s Primary CNA must be consulted to choose the proper candidate to use.

See Handling Duplicate Public CVE Identifiers for a detailed explanation of the criteria MITRE uses for selecting the preferred identifier.

corner corner

Vendor Liaisons

As can be seen by the requirements for a CNA described above, it can be resource-intensive and technically difficult to act as a CNA. Many vendors may want to participate properly in the CVE Initiative but not have the capability or desire to act as a CNA. A vendor liaison may work with another CNA to obtain or verify CVE candidates in the liaison’s own products, and include candidate numbers in its advisories.

Researcher Responsibilities

The researcher must reserve candidates for a particular vulnerability from only one CNA. If the affected software vendor is a CNA, then the researcher must obtain the candidate from the vendor. The researcher needs to provide the CNA with enough details for the CNA to apply CVE content decisions. The researcher has to coordinate the exchange of the candidate number across all involved parties. Finally, the researcher must include the candidate number in an advisory and publish the information through known reliable channels (vendor or response team), or known public channels with peer review (such as Bugtraq or NTBugtraq).

Researchers could adversely affect the reservation process in several different ways that could impact the overall quality of CVE. For example, the researcher’s disclosure process may frequently result in duplicate candidates, e.g., by refusing to work with a vendor. The researcher may frequently publish issues that are discovered to be false or so error-prone as to cause their associated candidates to be rejected by the Editorial Board. It is the responsibility of MITRE and the CNAs to identify and resolve such abuses.

Obtaining Candidate Numbers

In most instances the CVE Initiative does not issue CVE candidates directly but instead relies on certain mechanisms to handle newly emerging information that is eventually provided to CVE. Therefore, to receive a candidate number for your issue you could:

  • Contact one of the CNAs listed above, which will then include a candidate number in its initial public announcement about your new vulnerability.
  • Contact an emergency response team such as CERT/CC, DOE-CIAC, CanCERT, etc.
  • Post the information to mailing lists such as Bugtraq or NTBugtraq.
  • Provide the information to a vulnerability analysis team.

Alternatively, you may contact cve@mitre.org and we will provide you with our "CVE Candidate Reservation Guidelines For Researchers" and work with you to assign a CVE candidate number while you work through the process of publicly disclosing the vulnerability. Please review the Researcher Responsibilities.

 
Page Last Updated: September 16, 2009