Cybersecurity glossary
What is Common Vulnerabilities and Exposures (CVE)?
Learn what a CVE is, how CVE IDs are assigned and published, how NVD and CNA workflows work, and how security teams use CVEs for patching and risk prioritization.
Definition
Common Vulnerabilities and Exposures (CVE) is a public catalog of uniquely numbered security flaws. Each CVE ID (for example CVE-2024-12345) identifies one distinct vulnerability so vendors, scanners, and defenders can refer to the same issue without ambiguity.
Why CVE IDs matter
Security teams drown in advisories, scanner output, and vendor bulletins that describe the same bug with different titles. Common Vulnerabilities and Exposures (CVE) solves that coordination problem: one ID, one shared reference point across tools, tickets, and patch pipelines.
Without CVE, prioritization meetings dissolve into “is this the OpenSSL thing from last week?” With CVE, you can say “CVE-2014-0160,” pull NVD and vendor data, and act.
How a CVE record comes to life
Researcher or vendor finds a flaw
A bug is discovered through testing, hunting, customer reports, or coordinated disclosure.
A CNA reserves a CVE ID
An authorized numbering authority assigns a unique identifier for that distinct issue.
Record is published
A description, affected products, and references become public (sometimes after an embargo).
Enrichment and scoring follow
NVD and vendors add CVSS, CWE mappings, CPE matches, and fix guidance.
Defenders operationalize the ID
Scanners, SBOMs, and patch workflows track exposure and remediation by CVE.
What a CVE is—and is not
Shared vocabulary
One ID lets scanners, SIEMs, and humans correlate the same flaw across environments.
Not a severity score
CVE itself does not rank risk. CVSS, EPSS, KEV, and business context do that.
Not a complete advisory
Vendor notes still matter for exact versions, workarounds, and upgrade paths.
Not every bug
Misconfigurations, logic flaws, and private issues may never receive a CVE ID.
Using CVEs in vulnerability management
| Practice | Why it helps |
|---|---|
| Inventory with CPE / packages | Accurate matching depends on knowing what you run |
| Join CVE + CVSS + EPSS + KEV | Severity, exploit likelihood, and active abuse together beat any single signal |
| Track fix verification | Closing a ticket requires confirming the CVE is gone on each asset |
| Watch reserved / disputed states | Early IDs and contested records need careful handling |
| Prefer vendor advisory as source of truth | Product owners know which builds are fixed |
- Treat CVE as the correlation key across scanners, tickets, and change records.
- Enrich each CVE with CVSS, EPSS, CISA KEV status, and asset exposure before prioritizing.
- Map findings to owners via SBOM or package inventory—not by CVE title alone.
- Verify remediation with a re-scan or version check tied to the same CVE ID.
- Do not ignore non-CVE risks: authz bugs and misconfigurations still need triage.
- Subscribe to CNA and vendor feeds for products you actually deploy.
- Document exceptions when a CVE is accepted risk with compensating controls.
- Train engineers to paste CVE IDs in PRs and incident notes for searchable history.
The practical takeaway
A CVE is a public handle for a known vulnerability—not a score, not a patch, and not a guarantee that every flaw is listed. Use IDs to align people and tools, then prioritize with scoring, exploitation evidence, and business impact.
If your backlog only says “OpenSSL issue,” rename tickets to the CVE so the next engineer (and the next scanner) can finish the job.
Related security terms
Common Vulnerability Scoring System (CVSS)
Severity scoring commonly attached to CVE records in NVD and vendor advisories.
Common Weakness Enumeration (CWE)
Classifies the underlying weakness type that a CVE instance may exemplify.
Exploit Prediction Scoring System (EPSS)
Probability model used alongside CVE lists to prioritize likely exploitation.
Zero-Day Exploit
Attacks against flaws that may not yet have a public CVE or patch.
Vulnerability Assessment
Process that discovers and maps findings to CVE IDs where applicable.
Frequently asked questions
What is a CVE in simple terms?
A CVE is a public ID for a known security bug—like a license plate—so everyone can talk about the same vulnerability instead of inventing different names.
Who assigns CVE IDs?
CVE Numbering Authorities (CNAs)—including many vendors and MITRE as the primary CNA—assign IDs under the CVE Program operated by MITRE with sponsorship from CISA.
Is a CVE the same as a patch?
No. A CVE identifies the flaw. Fixes come from vendor advisories, package updates, or configuration changes linked to that ID.
How is CVE different from CWE?
CVE names a specific vulnerability instance in a product. CWE names a weakness category (for example SQL injection) that many CVEs can share.
Does every vulnerability get a CVE?
No. Some bugs stay private, are too product-specific for the program, or are tracked only in vendor bulletins. CVE coverage is broad but not universal.
Where should I look up CVE details?
Start with the CVE record, then NVD for enriched metadata and CVSS, plus the vendor advisory for accurate fix versions and workarounds.
How do scanners use CVEs?
They match installed software versions and configurations against CVE catalogs and local CPE/package maps to flag affected assets.
References
Explore authoritative guidance and frameworks related to common vulnerabilities and exposures (cve).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.