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 vulnerability reporting obligation to 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	~240,000+ (as of early 2026)
New CVEs per year	~25,000–30,000 (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 ENISA notification	Triggered when a CVE affecting your product is actively exploited
No known vulnerabilities at shipment	All CVEs matching your SBOM components must be patched before market placement
5-year vulnerability management	CVE monitoring must continue for the product’s entire support lifetime
OTA updates	CVE-triggered patches must be delivered to deployed devices

The SBOM–CVE Connection

Your product’s SBOM is the key to automated CVE monitoring:

SBOM Component	CVE Risk Example
FreeRTOS 10.4.3	CVE-2021-31571 — buffer overflow in TCP/IP stack
mbedTLS 2.28.0	CVE-2023-43615 — certificate validation bypass
lwIP 2.1.3	CVE-2023-36321 — denial of service via malformed packet
U-Boot 2023.04	CVE-2024-xxxxx — secure boot bypass via crafted image
Linux kernel 5.15	Hundreds of CVEs per year — continuous monitoring essential

The automated pipeline: SBOM → CPE matching → CVE database lookup → severity filtering → ENISA report generation → 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) × product exposure.
Patch or mitigate — deliver fixes via OTA update or publish mitigation guidance.
Report to ENISA — if actively exploited, trigger 24h/72h/14d reporting workflow.

SBOM — The component inventory that enables automated CVE matching.
ENISA — The EU agency that receives vulnerability reports triggered by CVEs.
CRA — The regulation mandating CVE monitoring and vulnerability management.
OTA Update — The delivery mechanism for CVE-triggered security patches.

CVE