Wiki · Concept · Last reviewed June 25, 2026

Common Vulnerabilities and Exposures (CVE)

Common Vulnerabilities and Exposures, usually shortened to CVE, is the public identifier layer for disclosed cybersecurity vulnerabilities.

Category: Concept Updated: June 25, 2026 Tags: AI security, CVE, vulnerability management, SBOM, EPSS, VEX, governance

Definition

Common Vulnerabilities and Exposures is the naming system that lets separate security reports point to the same publicly disclosed vulnerability. The CVE Program describes its mission as identifying, defining, and cataloging publicly disclosed cybersecurity vulnerabilities. A CVE ID does not prove severity, exploitability, compromise, or remediation status. It gives the ecosystem a shared key.

That key matters because vulnerability management is a distributed conversation. A vendor advisory, scanner result, AI Bill of Materials, package inventory, VEX statement, EPSS score, patch note, and incident ticket can all refer to one CVE ID while adding different context.

For AI systems, CVE mainly governs the conventional software around the model: model servers, inference runtimes, containers, browsers, drivers, databases, connectors, CI systems, and open source packages. Many AI-specific hazards need separate risk records unless they are also represented as public cybersecurity vulnerabilities through the CVE process.

How It Works

CVE Numbering Authorities, or CNAs, are organizations authorized by the CVE Program to assign CVE IDs and publish CVE Records within an agreed scope. The CVE List V5 repository is the official CVE List and hosts CVE Records in the CVE Record Format. The CVE schema project describes that format as JSON data used by CNAs and Authorized Data Publishers to describe a CVE Record, including items such as the CVE ID, affected products, affected versions, and public references.

The current official CVE Record Format in CVE JSON is version 5.2.0, released in 2025 with support for Package URL identifiers in affected product entries. Package coordinates help correlate Python, JavaScript, container, or model-serving dependencies across scanners and inventories.

NIST's National Vulnerability Database adds enrichment around CVEs. In April 2026, NIST announced a risk-based NVD operations model because CVE submissions grew sharply between 2020 and 2025. Under that model, all submitted CVEs are still listed in the NVD, but immediate enrichment is prioritized for categories such as CISA Known Exploited Vulnerabilities, software used within the federal government, and critical software.

Agent Context

Agentic systems make CVE hygiene more important because an agent can add dependencies, launch tools, open network paths, alter build files, or move data through connectors. A scanner finding therefore needs a trail from CVE ID to package identity, installed version, runtime path, exposure, owner, mitigation, and deployment state.

CVE should not be treated as a complete agent-risk vocabulary. It is strong for public software flaws in components. It is weaker for emergent workflow failures, bad tool permissions, poisoned context, retrieval leakage, or policy bypasses that do not map to a disclosed vulnerability in a product. Those risks still need controls such as AI Agent Sandboxing, AI Agent Observability, and OWASP AI Vulnerability Scoring System.

Governance and Safety

A governance-grade CVE record inside an organization should store the CVE ID, source URL, affected product or package identifier, version evidence, asset owner, exposure, severity source, EPSS or KEV status, VEX status, patch or mitigation decision, exception owner, and review date. The same CVE may deserve urgent patching on an internet-facing gateway and delayed remediation inside an isolated development image.

The main mistake is to let the identifier become the judgment. A CVE is neither a panic button nor a dismissal. It is a public handle that lets evidence accumulate. Risk still depends on whether the vulnerable code is present, whether it is reachable, whether exploitation is observed or likely, what the asset controls, and whether compensating controls are real.

Defense Pattern

Source Discipline

Security reports should distinguish CVE from related identifiers. CVE names the vulnerability record. CVSS estimates technical severity. CWE names a weakness class. CPE and PURL identify products or packages. EPSS estimates exploitation likelihood. KEV indicates known exploitation. VEX asserts product-specific affected status. Mixing these labels creates false certainty.

A clean citation says which CVE record, advisory, database, or repository supplied the claim. If a scanner says a dependency is affected, cite the scanner result and the underlying CVE source. If a supplier says a product is not affected, cite the VEX or advisory statement and preserve its scope.

Spiralist Reading

Spiralism reads CVE as a public naming rite for wounds in software infrastructure. The identifier does not heal the system. It makes the wound referable across institutions that otherwise speak incompatible dialects: vendor, scanner, regulator, buyer, researcher, maintainer, insurer, and operator.

The discipline is to keep the name humble. A CVE ID is a doorway into evidence, not the evidence itself.

Open Questions

Sources

Return to Wiki