Common Vulnerabilities and Exposures is a list of standardized identifiers for publicly known computer vulnerabilities. CVE is designed to cataloge and standardize the names for all publicly known vulnerabilities and exposures through the use of a unique identifier which may be used to refer to a specific vulnerability unambiguously.

Overview

Launched in 1999, CVE is maintained by The MITRE Corporation. The list is federally funded by the National Cyber Security Division (NCSD) of the U.S. Department of Homeland Security (DHS). MITRE maintains the list through an editorial board (operates per the CVE Board Charter) consisting of a board range of members from industry, research institutions, vendors, government agencies, security experts, and other individuals.

• CVE List - https://cve.mitre.org/cve/
• CVE List Download - https://cve.mitre.org/data/downloads/index.html
• CVE List Search - https://cve.mitre.org/cve/search_cve_list.html

Motivation

Prior to the CVE, two otherwise identical vulnerabilities were referred to by different names. Each company might have even published a paper talking about the issue and mitigating. It became increasingly difficult to associate articles, papers, and other resources proof of concepts that refer to the same issue with each other. The CVE eliminates those ambiguities that would otherwise arise through the use of a unique identifier that can be referred to by all applicable parties, making tracking, discussing, and working with easier.

Mechanism

The CVE is a list of all publicly known exposures and vulnerabilities. When a new vulnerability is discovered, it is submitted to the CVE. Upon submission, the issue is assigned a CVE identifier. Note that a CVE is issued right away (i.e., an identifier is issued even if it duplicates another issue or if the issue is not really a vulnerability). Once issued the CVE can be used when communicating with manufacturers and vendors in order to make sure things such as documentations refer to the same issue. This can be done even before the CVE is formally approved and is a great benefit of submitting for the CVE early.

Once the review of the entry concludes, the entry might be marked as "REJECT" if it is not accepted to the CVE list. When that happens, the reason for the rejection can be found in the description field of the entry. A common reason for an entry to be rejected is due to being a duplicated entry, a mistake, or was withdrawn by the author.

CVE Entry

Each CVE Entry consists of the following:

• CVE ID
• Status
• Description
• References
• Date Entry Created

Additionally, there are a number of legacy fields:

• Phase
• Votes
• Comments
• Proposed

CVE ID

A CVE ID' (also "CVE number", "CVE name", and "CVE Identifier") is a unique common identifiers for publicly known cybersecurity vulnerabilities designed to unambiguously reference a specific issue. An example CVE ID would be "CVE-2018-1234" and "CVE-2006-4529". The syntax for a CVE ID is CVE-YYYY-NNNN.

The YYYY portion of the CVE ID refers to the year the CVE was created. If the vulnerability was made public prior to the CVE creation year, then the year will be the year the vulnerability was first made public instead. For example, if the vulnerability was made public in December 2015 but the CVE wasn't created until 2016, the CVE ID will be CVE-2015-NNNN.

Note that as of January 1 2014, CVE ID can have an arbitrary number of digits.

Status

A CVE can have a different status depending on the reason:

• REJECT - Entry was not accepted as a CVE Entry (e.g., duplicate entry).
• RESERVED - Entry was reserved by a submitter but its details are being withhold. Typically the reason is because this is an ongoing vulnerability that has not been made public (e.g., under embargo).
• DISPUTED - Entry received a disagreement/dispute by a different part concerning this particular entry. Note that CVE doesn't made a determination as to which party is correct and therefore it is the responsibility of the user to research the issue.

Description

The description field includes a unique and concise description of the issue. This is typically written by the CVE requester, CVE team, or the CNAs. The description usually detail things such as the version of the software or hardware vulnerable, affected products and vendors, possibly a note that distinguishes it from other similar-looking vulnerabilities, and an except of the issue.

References

A list of URLS that can be used to identify the source, the issue, or include other well-established articles that address the issue or provide additional information.

Date Entry Created

This is the date the CVE entry was created.

Historical

Prior to 2006, CVEs were initially assigned a "candidate" status and were assigned a CAN-YYYY-NNNN identifier to indicate that this is an issue under review for inclusion on the CVE list. Once review complete and the issue is approved, the status was changed to "entry" which was used to indicate that the identifier has been formally accepted to the list. When that happened, the identifier was changed to CVE-YYYY-NNNN. The use of two IDs before and after approval resulted in companies needing to change the CAN identifier to CVE in articles and documentations and other tools used to track those issues. Following a request by the community, there are no candidate identifiers anymore and all issues are assigned a CVE identifier right away which can be use to reference the issue immediately.