Vulnerabilities

What is a vulnerability

A software vulnerability is a weakness or flaw in code, configuration, or design that an adversary can exploit to perform unauthorized actions. Vulnerabilities range from implementation errors (buffer overflows, injection flaws) to design-level weaknesses (broken authentication, insufficient access control).

Vulnerabilities fall into two categories based on disclosure status:

• Public vulnerabilities are assigned identifiers in public databases (CVE, NVD, EUVD) and tracked through established catalogues. Security teams, tooling, and automated scanners can match these identifiers against component inventories.
• Private vulnerabilities are discovered internally or reported through coordinated disclosure but have not yet received public identifiers. Producers communicate these to consumers through VDR documents. Some private vulnerabilities never receive a CVE, either because the producer patches them before public disclosure or because they fall outside CVE scope.

Coordinated vulnerability disclosure is the standard practice for managing this transition. A researcher or internal team discovers a flaw, reports it privately to the vendor or maintainer, and both parties agree on a timeline for remediation and public disclosure. Coordinated disclosure gives the producer time to develop and distribute a fix before the vulnerability becomes public knowledge. Disclosure timelines vary by severity and vendor responsiveness, though 90 days is a common baseline. For the specific field-level requirements that VEX and VDR documents must meet, see VEX / VDR. For vulnerability identifier requirements, see Vulnerabilities.

The CVE system

The Common Vulnerabilities and Exposures (CVE) program provides a globally accessible catalogue of publicly disclosed cybersecurity vulnerabilities. Each vulnerability receives a unique CVE identifier, allowing different tools, databases and organizations to reference the same issue without ambiguity. The program is maintained by the MITRE Corporation (operating as a Federally Funded Research and Development Center) and sponsored by the U.S. Department of Homeland Security through CISA.

CVE identifiers follow the format CVE-YYYY-NNNNN, where the year reflects when the ID was reserved or published, not when the vulnerability was discovered. A CVE with a 2024 year component may describe a vulnerability discovered in 2023 but reserved for coordinated disclosure in 2024.

Key actors

The CVE program operates through a federated hierarchy of organizations, each with defined responsibilities:

Top-Level Roots (TL-Roots) report directly to the CVE Board and oversee the program's structure. Currently there are two: CISA and MITRE.

Roots manage groups of CVE Numbering Authorities and handle organizational functions such as onboarding new CNAs, oversight and dispute resolution. Examples include ENISA, Google, JPCERT/CC and Red Hat.

CVE Numbering Authorities (CNAs) perform the operational work: receiving vulnerability reports, validating them, assigning CVE IDs and publishing CVE Records. CNAs include software vendors, open-source project maintainers, security research organizations, bug bounty providers and national CERTs. Over 400 CNAs operate worldwide, each with a defined scope covering specific products or project families. This distributed model allows vulnerabilities to be identified and published without relying on a single central authority.

CNA of Last Resort (CNA-LR) is a specialized CNA designated by its Root to assign CVE IDs when no regular CNA covers the vulnerability or when a dispute arises. CNA-LRs ensure that reporters have a path to obtain a CVE ID even when regular CNAs decline.

Authorized Data Publishers (ADPs) enrich CVE Records with additional information (risk scores, CWE classifications, CPE applicability, translations) without modifying the data supplied by the CNA. ADP updates are stored in a separate container within the CVE Record. CISA is currently the only active ADP, enriching records with SSVC triage decisions and Known Exploited Vulnerabilities (KEV) data.

CVE Record lifecycle

A CVE Record moves through six stages:

1. Discover. A researcher or organization identifies a vulnerability.
2. Report. The discoverer reports the vulnerability to a CNA or another CVE Program partner.
3. Request. The CNA validates the report and assigns a CVE ID.
4. Reserve. The ID is held in the Reserved state while the affected parties coordinate remediation. The CNA may use the ID privately but has not yet published details.
5. Submit. The CNA provides vulnerability details to the CVE system: affected products and versions, vulnerability type, a prose description and at least one public reference.
6. Publish. The CNA publishes the CVE Record to the CVE List, changing its state to Published. Records may also be marked Rejected if the CVE is invalid or a duplicate.

CVE Records are stored as JSON documents. Each record contains exactly one CNA container (the authoritative vulnerability data from the assigning CNA) and optionally one or more ADP containers (enrichment data from Authorized Data Publishers). The CVE List on cve.org is the system of record. For the terminology used throughout this framework, including CVE, CWE, and related terms, see Artifact Fundamentals.

Vulnerability databases and advisory sources

CVE List (cve.org) is the authoritative source of CVE Records. It catalogues vulnerabilities with identifiers, descriptions, affected products and references. The CVE List identifies and names vulnerabilities; it does not score or classify them.

National Vulnerability Database (NVD) consumes the CVE List and enriches each record with additional metadata. NVD enrichment includes CVSS severity scores, CWE weakness classifications, CPE applicability statements (mapping vulnerabilities to specific software and hardware products) and reference tagging. CVE and NVD are separate programs: the CVE List feeds NVD, and NVD enrichments do not overwrite CNA data. NVD is operated by NIST.

EU Vulnerability Database (EUVD)

The European Vulnerability Database is operated by ENISA under the NIS2 Directive (Article 12(2) of Directive (EU) 2022/2555). Launched in 2025, it provides an EU-focused vulnerability catalogue.

EUVD assigns its own identifiers (EUVD IDs) and cross-references CVE entries. It organizes vulnerabilities across three dashboard views:

• Critical vulnerabilities with CVSS scores of 9.0 or higher
• Exploited vulnerabilities confirmed as actively exploited
• EU-coordinated vulnerabilities handled through European CSIRTs

Each entry includes CVSS scores, affected products, external advisories and mitigation information where available. The EU Cyber Resilience Act (CRA) guidance references EUVD as one of the databases that determines whether a vulnerability is considered "known" by a manufacturer, which triggers specific obligations under the regulation.

GitHub Security Advisories (GHSA) cover vulnerabilities in open-source packages hosted on GitHub. GHSA identifiers serve as the primary reference for many open-source dependencies and are cross-referenced with CVE IDs when available.

Vendor-specific advisories are published by software and hardware vendors for their own products. These may include vulnerabilities not yet assigned CVE IDs, or provide vendor-specific context (affected configurations, workarounds, patch availability) beyond what the CVE Record contains.

Scoring and prioritization

CVSS

The Common Vulnerability Scoring System quantifies the severity of a vulnerability through a structured set of metrics. Each metric captures a specific characteristic of the vulnerability: attack vector, exploitation complexity, required privileges, user interaction, and impact on confidentiality, integrity or availability. These metrics are encoded as a vector string and combined into a composite score on a 0.0 to 10.0 scale.

CVSS defines three metric groups: base metrics describe intrinsic properties of the vulnerability, temporal metrics capture characteristics that change over time (exploit availability, remediation status), and environmental metrics let organizations adjust the score to their own deployment context.

CVSS v3.1 is the most widely deployed version. CVSS v4.0 refines the metric structure and scoring methodology. Both versions are in active use.

A CVSS base score reflects severity in isolation. It does not predict whether a vulnerability will be exploited or account for an organization's specific exposure. A vulnerability scored 9.8 in a component running on an isolated, air-gapped system may pose less operational risk than a 6.5 in a public-facing authentication service.

EPSS

The Exploit Prediction Scoring System estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. EPSS uses machine learning models trained on observed exploitation activity, vulnerability characteristics and threat intelligence data.

EPSS scores range from 0 to 1 (0% to 100% probability). CVSS measures severity; EPSS measures likelihood of exploitation. A vulnerability with a high CVSS score but a low EPSS score may warrant monitoring rather than immediate remediation.

SSVC

Stakeholder-Specific Vulnerability Categorization provides a decision-tree approach to vulnerability triage. Rather than producing a numeric score, SSVC guides organizations through a series of structured questions to arrive at a prioritized action: Track, Track*, Attend, or Act.

SSVC decision points include the current state of exploitation, whether the vulnerability is automatable (can be exploited at scale without manual effort), and the technical impact on the affected system. Organizations can customize decision trees to reflect their own risk tolerance and operational context.

CISA uses SSVC as part of its ADP enrichment of CVE Records, recording exploitation status, automatability and technical impact for each new CVE.

KEV

The Known Exploited Vulnerabilities catalog, maintained by CISA, lists vulnerabilities confirmed as actively exploited in the wild. Inclusion in KEV confirms active exploitation.

For U.S. federal agencies, KEV entries carry mandatory remediation deadlines under Binding Operational Directive 22-01. Outside the federal mandate, KEV serves as a high-confidence signal for prioritization. A vulnerability in the KEV catalog warrants immediate attention regardless of its CVSS score or EPSS probability.

How these concepts connect to the framework

Each transparency artifact addresses a different stage of vulnerability identification and response:

• SBOM identifies the components in a product. When a new CVE is published, organizations query their SBOM inventory to determine which products contain the affected component, at which version, and in what deployment context.
• VEX communicates whether a specific vulnerability affects a specific product. A producer issues a VEX document to state that a CVE listed against a component does not affect their product (for example, because the vulnerable code path is not reachable), or to confirm that it does and describe the response.
• VDR discloses vulnerabilities that may not appear in public databases. Producers use VDR documents to provide consumers with the information needed for risk assessment even when no CVE exists.

For field-level requirements on how to represent vulnerability data in these artifacts, see Vulnerabilities and VEX / VDR.