CVE — Common Vulnerabilities and Exposures
CVE (Common Vulnerabilities and Exposures) is a globally recognized system for identifying and naming cybersecurity vulnerabilities. Each vulnerability receives a unique CVE-ID (e.g., CVE-2024-3094) that allows security teams, manufacturers, and regulators to unambiguously reference the same vulnerability. Under the EU Cyber Resilience Act, CVE monitoring is essential for meeting the 24-hour early-warning obligation for actively exploited vulnerabilities, submitted through the single reporting platform operated by ENISA.
Key Facts
| Detail | Information |
|---|---|
| Full name | Common Vulnerabilities and Exposures |
| Maintained by | MITRE Corporation (U.S., funded by CISA) |
| ID format | CVE-YYYY-NNNNN (year + sequential number) |
| Total CVEs published | Over 300,000 (as of early 2026) |
| New CVEs per year | ~40,000 in 2024, ~48,000 in 2025 (accelerating) |
| Public database | cve.org |
| Enrichment database | NVD (National Vulnerability Database) — adds CVSS scores, CPE matches |
| EU equivalent | ENISA maintains EU Vulnerability Database (mandated by NIS2) |
How CVEs Work
Lifecycle of a Vulnerability
+--------------------------------------------------------+
| 1. DISCOVERY |
| Researcher / vendor / attacker finds vulnerability |
+--------------------------------------------------------+
↓
+--------------------------------------------------------+
| 2. CVE ASSIGNMENT |
| CNA (CVE Numbering Authority) assigns CVE-ID |
| Reserved but not yet public |
+--------------------------------------------------------+
↓
+--------------------------------------------------------+
| 3. PUBLICATION |
| CVE record published on cve.org |
| Includes: description, references, affected products |
+--------------------------------------------------------+
↓
+--------------------------------------------------------+
| 4. NVD ENRICHMENT |
| NVD adds: CVSS score, CPE matches, CWE category |
| Appears in automated scanning tools |
+--------------------------------------------------------+
↓
+--------------------------------------------------------+
| 5. REMEDIATION |
| Vendor releases patch / firmware update via OTA |
| Product SBOM updated to reflect fixed versions |
+--------------------------------------------------------+CVSS Severity Scoring
Each CVE receives a CVSS (Common Vulnerability Scoring System) score indicating severity:
| CVSS Score | Severity | Example Impact |
|---|---|---|
| 9.0–10.0 | Critical | Remote code execution, complete device takeover |
| 7.0–8.9 | High | Privilege escalation, authentication bypass |
| 4.0–6.9 | Medium | Information disclosure, denial of service |
| 0.1–3.9 | Low | Minor information leak, theoretical exploit |
Why CVEs Matter for Hardware Manufacturers
CRA Vulnerability Reporting
The CRA creates a direct link between CVE monitoring and legal obligations:
| CRA Requirement | CVE Connection |
|---|---|
| 24-hour early warning (to the coordinator CSIRT and ENISA) | Triggered when a vulnerability in your product is actively exploited |
| No known exploitable vulnerabilities when made available | CVEs matching your SBOM components must be assessed; those exploitable in the product must be fixed before it is made available on the market |
| Vulnerability handling for the support period (at least 5 years, unless the product is expected to be in use for less) | CVE monitoring must continue for the whole support period |
| Security updates (for example via OTA) | Fixes for exploitable vulnerabilities must reach deployed devices without delay |
The SBOM–CVE Connection
Your product’s SBOM is the key to automated CVE monitoring:
| SBOM Component | CVE Risk Example |
|---|---|
| FreeRTOS kernel 10.4.2 | CVE-2021-31571 — integer overflow in queue creation |
| mbedTLS 2.28.0 | CVE-2023-43615 — buffer overread in TLS stream-cipher suites |
| lwIP 2.1.3 | CVE-2026-119053 — out-of-bounds read in the SNMP agent |
| U-Boot 2023.04 | CVE-2024-57256 — memory overwrite via crafted ext4 filesystem |
| Linux kernel 5.15 | Hundreds of CVEs per year — continuous monitoring essential |
The automated pipeline: SBOM → CPE matching → CVE database lookup → severity filtering → CRA notification drafting → OTA patch deployment. This is what our SBOM Monitoring Service provides.
CVE Monitoring for Embedded Products
Challenges Specific to Embedded/IoT
| Challenge | Description |
|---|---|
| Long deployment cycles | IoT devices deployed for 10–15 years; CVEs accumulate over time |
| Constrained resources | Devices may lack bandwidth/storage for frequent patches |
| Component lag | Embedded vendors often use older versions of open-source components |
| Custom BSP | Board Support Packages from silicon vendors may contain untracked components |
| Nested dependencies | Transitive dependencies (deps of deps) are often not in the SBOM |
| No centralized updater | Unlike mobile OS, each manufacturer manages their own update pipeline |
Recommended Monitoring Workflow
- Generate SBOM at build time (SPDX or CycloneDX format).
- Map components to CPE identifiers for NVD database matching.
- Continuous CVE scanning — automated daily or real-time checks against NVD/EPSS feeds.
- Risk-based triage — prioritize by CVSS score, EPSS (Exploit Prediction Scoring System) and product exposure.
- Patch or mitigate — deliver fixes via OTA update or publish mitigation guidance.
- Report through the ENISA single reporting platform — if actively exploited, trigger the 24-hour early warning, the 72-hour notification and the final report.
Related Terms
- SBOM — The component inventory that enables automated CVE matching.
- ENISA — The EU agency operating the single reporting platform for CRA vulnerability notifications.
- CRA — The regulation requiring vulnerability handling, for which CVE monitoring is a core practice.
- OTA Update — The delivery mechanism for CVE-triggered security patches.
Official References
- CVE Program — MITRE Corporation — MITRE (CVE database and numbering authority)
- National Vulnerability Database (NVD) — NIST (enriched CVE data with CVSS scores)