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 made up 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 able to reserve a CVE ID when the need arises. 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 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 National Vulnerability Database enrichment efforts (see below).

NVD Scope of Coverage

NVD enrichment activities intend to address CVEs that have the greatest potential impact on the nation’s cybersecurity. The following CVEs are considered to be part of NVD’s Scope of Coverage:

• CVEs appearing in CISA’s Known Exploited Vulnerabilities (KEV) Catalog.
• Within one business day of addition to the KEV Catalog
• CVEs for software used within the federal government
• CVEs for Critical Software as defined by Executive Order 14028

EO Order 14028 Critical software is defined as any software that has direct software dependencies (and one or more components with at least one of these attributes):

• It is designed to run with elevated privilege or managed privileges
• It has direct or privileged access to networking or computing resources
• It is designed to control access to data or operational technology
• It performs a critical function to trust, or it operates outside of normal trust boundaries with privileged access

NVD CVE Enrichment

The National Vulnerability Database (NVD) enriches a CVE within NVD’s Scope of coverage after a CVE is in the NVD. CVEs published to the CVE List are typically available in the NVD within an hour of their publication to the CVE List. The amount of time needed for enrichment can vary depending on the CVE, the information available, and the quantity of CVEs published within a given timeframe. NVD enrichment efforts use the reference information provided with the CVE and any publicly available information at the time of enrichment to associate Reference Tags, Common Vulnerability Scoring System (CVSS) v4.0, CVSS v3.1, CWE, and CPE applicability statements. As of July 13th, 2022, the NVD no longer generates CVSS v2.0 enrichment data for CVE records.

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

1. Enrichment efforts begin with reviewing 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. Enrichment efforts also include manual searches of the internet to ensure that any other available and relevant information is used for the enrichment process. NVD enrichment efforts only use publicly available materials in the enrichment process.
2. A common weakness enumeration (CWE) identifier is assigned that categorizes the vulnerability. NVD enrichment efforts 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 V3.1 exploitability and impact metrics are assigned based on publicly available information and the guidelines of the specification if a CVSS score has not already been assigned. If an existing score is noticed to not be supported by CVSS guidelines or publicly available information while performing other enrichment activities, an enrichment team member may choose to provide a score. Users of NVD data may also request the NVD to provide a score.
4. A Common Platform Enumeration (CPE) Applicability Statement is associated with the vulnerability. The CPE match criteria are generated to identify 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. Every effort is made to identify all vulnerable software, but gaps may exist and feedback is encouraged to improve this information.
5. Enrichment effort results are given a quality assurance check by another experienced team member prior to being published to the website and data feeds.

CVE Maintenance

Once a CVE is published and NVD enrichment is provided, additional maintenance or modifications may be made. References may be added or removed, 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 always appreciates and encourages feedback from the community to keep the dataset and CPE Dictionary accurate and current.