Overview
Common Vulnerabilities and Exposures (CVE) is a dictionary of common identifiers for publicly known cyber security vulnerabilities and exposures. It was created in 19999 and operated by MITRE, under the sponsorship of U.S. Department of Homeland Security (DHS) and Cybersecurity and Infrastructure Security Agency (CISA).
The goal of the CVE program is to communicate consistent descriptions of vulnerabilities among the cyber security professionals in order to coordinate their efforts to prioritize and address the known vulnerabilities. It helps security professionals especially by providing a standardized vulnerability identifier that can be used to accurately access information about a given vulnerability across multiple databases, tools and services.
In the CVE dictionary, for each vulnerability, there exists one CVE record that comprises of 3 elements, i.e., a CVE ID, a brief description and references. These fundamental properties are very useful, especially in discussing the same vulnerabilities without any naming confusions via the unique CVE IDS. However, CVE dictionary is not regarded as a vulnerability database as more detailed and technical information such as risk, impact, fix etc. are not contained in the CVE dictionary.
CVE Records
A CVE record in the CVE dictionary consists of the following 3 parts:
- CVE ID: A CVE ID is a unique identifier with the pattern CVE-YYYY-NNNNNN. It starts with the CVE prefix that is followed by a 4 digit year portion that represents the year when a CVE ID was assigned and the vulnerability was made public (rather than the discovery date of the vulnerability). What follows is a four or more digits that uniquely identifies a CVE for a given year. Some example CVEs are CVE-2019-18634, CVE-2021-33909, CVE-2021-40444.
- CVE Description: Descriptions are unique textual information that provide relevant details about the vulnerabilities. Descriptions are written by the CVE Numbering Authorities (CNAs) or the individuals that request CVE IDs. CVE descriptions mostly include details such as affected products and versions, type of the vulnerability, the impact of the vulnerability, the privileges required by the attackers to exploit the vulnerabilities etc. Note that the vulnerability descriptions are not formatted and do not follow a strict pattern that can be processed by computers in an automated fashion.
- References: Each record includes related references that can be useful in providing further technical details and fix information.
Requesting CVE IDs
Upon the discovery of a software, firmware or hardware vulnerability, a request needs to be made to the relevant CVE Numbering Authority (CNA) to assign a CVE ID for it. In the case that the requester is an individual security researcher, the correct CNA whose scope includes the product affected by the vulnerability should be located from a list of CNAs and contacted via the methods provided. As most of the CNAs are product vendors, CNAs could also assign CVE IDs on their own when they identify security flaws on their own products.
States of CVE Records
There are 4 different states that can be assigned to CVE record in the CVE dictionary.
- RESERVED: A CVE record is marked as “RESERVED” when a CVE ID is assigned to a vulnerability but vulnerability description and references for the vulnerability are not provided by a CNA or the security researcher. This especially happens when a CNA or security researcher wants to reserve a CVE ID upon its initial discovery but would like to provide further details about the vulnerability later.
- PUBLISHED: A vulnerability transitions to “PUBLISHED” state when vulnerability description and references are provided by a CNA or security researcher. At this stage, a vulnerability will become available at the U.S. National Vulnerability Database (NVD). Records that have been published at NVD could provide further vulnerability details such as impacts in the Common Vulnerability Scoring System (CVSS) format and the affected products in the Common Platform Enumeration (CPE) standard.
- DISPUTED: A vulnerability is marked as “DISPUTED” when one or more of the involved parties (such as product vendors, security researchers etc.) disagree with its current description. In this case, CVE program makes a note of the dispute rather than resolving the disputed case and making a final decision on such a vulnerability as an ultimate authority.
- REJECTED: A vulnerability becomes “REJECTED” when it is not regarded as a CVE record any more. This is mostly due to the circumstances such as detection of duplicates for some of the vulnerabilities or when the original requester thinks that a vulnerability was assigned incorrectly and it needs to be invalidated.
Searching for CVE Records
CVE records can be searched by keyword(s) or by CVE IDs on the CVE Search Page provided by MITRE or on the vulnerability search page (Depicted in Figure 1) provided by NIST National Vulnerability Database (NVD).
An excerpt for an example vulnerability (CVE-2019-18634) search result from the NVD vulnerability search page is shown in Figure 2.
CVEs can also be accessed via CVE Data Feeds or could be downloaded from the CVE Downloads Page in a variety of formats such as CSV, HTML, Text, XML and CVRF (Common Vulnerability Reporting Framework).
For more information on CVEs, we recommend our readers to refer to the CVE Frequently Asked Questions (FAQ) Page.
One single vulnerability all an attacker needs.
Window Snyder
Read more educational and inspirational cyber quotes at our page 100+ Best Cyber Security & Hacker Quotes.
References
- CVE MITRE
- CVE MITRE – Frequently Asked Questions (FAQ)
To learn more about fundamental cyber security terminology, you could also read our article What is Identification, Authentication and Authorization?
You could also read our popular articles What is a Security Vulnerability? or What is Vulnerability Scanning?
