U.S. flag   An official website of the United States government
Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Https

Secure .gov websites use HTTPS
A lock (Dot gov) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

National Vulnerability Database

National Vulnerability Database

NVD

  1. General

CVEs and the NVD Process

An Introduction

The Common Vulnerabilities and Exposures (CVE) program is a dictionary or glossary of vulnerabilities that have been identified for specific code bases, such as software applications or open libraries. This list allows interested parties to acquire the details of vulnerabilities by referring to a unique identifier known as the CVE ID. It has garnered increasing awareness in recent years, making it important for participants and users to understand the fundamental elements of the program.

Founded in 1999, the CVE program is maintained by the MITRE corporation and sponsored by the U.S. Department of Homeland Security (DHS) and the Cybersecurity and Infrastructure Security Agency (CISA). CVE IDs are primarily assigned by MITRE, as well as by authorized organizations known as CVE Numbering Authorities (CNAs)—an international group of vendors and researchers from numerous countries. The project has an advisory board comprised of significant players in cybersecurity research, academia, and software development communities.

The CVE program was created with the vision of becoming the industry standard in establishing a baseline for vulnerabilities, and all information contained in the project is publicly available to any interested party. This allows stakeholders a common means of discussing and researching specific, unique exploits. CVE IDs are also used by vendors and cybersecurity personnel for research and the identification of new vulnerabilities. (MITRE and CNAs do not assist in mitigating or patching vulnerabilities on the CVE list.)

The CVE Assignment and Vetting Process

CVE IDs are assigned by the CVE Assignment Team and CNAs. The diversity of CNAs provides varied yet specific areas of expertise for different types of vulnerabilities. Each CNA is given a realistic number of possible candidates based on their scope and ability to timely vet each one. Regular training and retraining of CNA staff and the establishment of a hierarchy of CNAs to govern various authorities help ensure that the guidelines for the process are strictly followed and that standards are being met.

CNAs use a policy known as the Counting Process in addition to an inclusion decision tree to determine if an individual vulnerability should be included in the CVE list and if more than one CVE ID needs to be assigned. This process begins when a reporter (typically the original individual or organization(s) that discovered the bug) contacts the CVE Assignment Team or an appropriate CNA to request a CVE ID.

Each CVE must include a description that is either provided by the reporter or created using the CVE Assignment Team’s optional template. This description includes the type of vulnerability (e.g., a buffer overflow, NULL pointer dereference, or cross-site request forgery), the product’s vendor, and the affected code base(s). Reporters can provide further information, such as the expected impact, attack vectors, or state of remediation. Once the vetting process is completed, a CVE ID is assigned.

RESERVED tags are used when CVE IDs have been assigned or potentially assigned to vulnerabilities which need further details before they can be finalized. Should the vulnerability be unsuitable for publication, it will be denied a CVE ID and tagged REJECTED by the CNA. This may occur due to a lack of qualifying factors, irregularities in the reporting process, or a request to be withdrawn by the original reporter.

A CVE ID also may be given a DISPUTED tag should the vendor or other authoritative entity challenge the validity of the vulnerability. This can occur before or after the National Vulnerability Database publishes their analysis (see below).

NVD CVE Analysis

The National Vulnerability Database (NVD) is tasked with analyzing each CVE once it has been published to the CVE List, after which it is typically available in the NVD within an hour. Once a CVE is in the NVD, analysts can begin the analysis process. The processing time can vary depending on the CVE, the information available, and the quantity of CVEs published within a given timeframe. NVD analysts use the reference information provided with the CVE and any publicly available information at the time of analysis to associate Reference Tags, Common Vulnerability Scoring System (CVSS) v2.0, CVSS v3.1, CWE, and CPE Applicability statements.

The following is a general overview of the analysis process for a given CVE:

  1. An analyst reviews any reference material provided with the CVE record and assigns appropriate reference tags. This helps organize the various data sources to help researchers find the relevant information for their needs. The analyst also performs manual searches of the internet to ensure that any other available and relevant information is used for the analysis process. NVD analysts only use publicly available materials in the analysis process.
  2. A common weakness enumeration (CWE) identifier is assigned that categorizes the vulnerability. NVD analysts use a subset of the full list of CWEs that best represents the distribution of specific types of vulnerabilities. This subset is known as the CWE-1003 view and was created through coordination with the MITRE CWE team.
  3. CVSS V2.0 exploitability and impact metrics are assigned based on publicly available information and the guidelines of the specification.
  4. CVSS V3.1 exploitability and impact metrics are assigned based on publicly available information and the guidelines of the specification.
  5. A Common Product Enumerator (CPE) Applicability Statement is associated with the vulnerability. The CPE match criteria identifies all potentially vulnerable software and/or hardware for the vulnerability. For example, an application may have several versions affected or must be running on a specific operating system to be vulnerable. Automated processes can reference match criteria within the applicability statements against the CPE dictionary to assist in identifying vulnerable products within an organization’s information system.
  6. Analysis results are given a quality assurance check by another more senior analyst prior to being published to the website and data feeds.

CVE Maintenance

Once a CVE is published and NVD analysis is provided, there may be additional maintenance or modifications made. References may be added, descriptions may be updated, or a request may be made to have a set of CVE IDs reorganized (such as one CVE ID being split into several). Furthermore, the validity of an individual CVE ID can be disputed by the vendor. The NVD does make efforts to reanalyze CVEs that have been changed after previous analysis. The NVD always appreciates and encourages feedback from the community to keep the database and CPE dictionary accurate and current.