CVE Numbering Authorities

Participating CNAs

The organizations below are participating as CVE Numbering Authorities (CNAs) as of October 2012:

Primary CNA

Software Vendors

  • Apple Inc. (Apple issues only)
  • Adobe Systems Incorporated (Adobe issues only)
  • Hewlett-Packard Development Company, L.P. (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)
  • Mozilla Corporation (Mozilla issues only)
  • Silicon Graphics, Inc. (SGI issues only)
  • EMC Corporation (EMC issues only)
  • Novell/SUSE (Novell issues only)
  • Google Inc. (Google issues only)
  • IBM Corporation (IBM issues only)
  • Research In Motion Limited (RIM issues only)
  • Symantec Corporation (Symantec issues only)

Third-Party Coordinators

  • CERT/CC
  • JPCERT/CC
  • ICS-CERT

Researchers

  • Core Security Technologies
  • Secunia

Introduction to CVE Identifier Reservation

CVE Identifier (CVE-ID) reservation allows responsible researchers, vendors, and incident response teams to include CVE-IDs in the initial public announcement of a vulnerability. It ensures that a CVE-ID 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 CVE-ID number(s).

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

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

(4) The requester includes the CVE-ID number(s) in the vulnerability advisory.

(5) The requester makes the CVE-ID(s) public and notifies MITRE.

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

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

Role and Requirements of CNAs

CNAs are organizations that distribute CVE-ID 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 CVE-ID 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 CVE-ID 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-IDs by providing additional access points for researchers and vendors to obtain CVE-ID 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 CVE-IDs 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 CVE-ID numbers across all involved parties (vendor, researcher, response team, etc.) in order to reduce the risk of producing duplicate CVE-ID numbers. CNAs must notify MITRE when CVE-IDs 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-ID 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 CVE-ID numbers across multiple parties, especially if more than one party reserves CVE-IDs from MITRE.

Communications from CNAs to MITRE

The following series of communications occur between CNAs to MITRE:

(1) The CNA requests a pool of CVE-ID numbers.

(2) The CNA announces the publication of a new CVE-ID, which allows MITRE to update the CVE-ID 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 CVE-IDs 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 CVE-ID numbers. Since a third party might gain a competitive advantage by initially providing CVE-ID numbers to a limited audience (outside of the researcher and vendor), the CNA should not publish CVE-ID 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 CVE-ID to other affected parties, e.g., other vendors, researchers, or response teams. They must include CVE-ID numbers in their own advisories. They can only use their pool of CVE-IDs for vulnerabilities in their own products. They must apply CVE content decisions to determine the proper number of CVE-IDs 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 CVE-IDs for that issue. Finally, when an issue has already been published and assigned a CVE-ID, the vendor must use the existing CVE-ID number.

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 CVE-ID to use.

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

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-IDs in the liaison’s own products, and include CVE-ID numbers in its advisories.

Researcher Responsibilities

The researcher must reserve CVE-IDs for a particular vulnerability from only one CNA. If the affected software vendor is a CNA, then the researcher must obtain the CVE-ID 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 CVE-ID number across all involved parties. Finally, the researcher must include the CVE-ID 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).

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 CVE-IDs, 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 CVE-IDs to be rejected by the CVE Editor. It is the responsibility of MITRE and the CNAs to identify and resolve such abuses.

Requesting CVE-ID Numbers

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

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

Alternatively, you may contact the CVE project to Request a CVE-ID and we will provide you with our "CVE Identifier Reservation Guidelines for Researchers" and work with you to assign a CVE-ID number while you work through the process of publicly disclosing the vulnerability. Please review the Researcher Responsibilities.

 
Page Last Updated: May 16, 2013