CVE — Common Vulnerabilities and Exposures
CVE (Common Vulnerabilities and Exposures) è un sistema riconosciuto a livello globale per l’identificazione e la denominazione delle vulnerabilità di cibersicurezza. A ciascuna vulnerabilità viene assegnato un CVE-ID univoco (ad es. CVE-2024-3094) che consente ai team di sicurezza, ai fabbricanti e alle autorità di regolamentazione di fare riferimento in modo inequivocabile alla stessa vulnerabilità. Ai sensi del Cyber Resilience Act dell’UE, il monitoraggio dei CVE è essenziale per adempiere all’obbligo di preallarme entro 24 ore per le vulnerabilità attivamente sfruttate, da trasmettere tramite la piattaforma unica di segnalazione gestita dall’ENISA.
Dati principali
| Dettaglio | Informazione |
|---|---|
| Denominazione completa | Common Vulnerabilities and Exposures |
| Gestito da | MITRE Corporation (USA, finanziata da CISA) |
| Formato dell’ID | CVE-AAAA-NNNNN (anno + numero sequenziale) |
| Totale CVE pubblicati | Oltre 300.000 (a inizio 2026) |
| Nuovi CVE all’anno | ~40.000 nel 2024, ~48.000 nel 2025 (in accelerazione) |
| Database pubblico | cve.org |
| Database di arricchimento | NVD (National Vulnerability Database) — aggiunge punteggi CVSS, corrispondenze CPE |
| Equivalente UE | L’ENISA gestisce il Database europeo delle vulnerabilità (previsto dalla NIS2) |
Come funzionano i CVE
Ciclo di vita di una vulnerabilità
┌────────────────────────────────────────────────────────────────────────┐
│ 1. SCOPERTA │
│ Un ricercatore, un fornitore o un attaccante scopre la vulnerabilità │
└────────────────────────────────────────────────────────────────────────┘
↓
┌────────────────────────────────────────────────────────────────────────┐
│ 2. ASSEGNAZIONE DEL CVE │
│ La CNA (CVE Numbering Authority) assegna un CVE-ID │
│ Il codice è riservato, ma non ancora pubblico │
└────────────────────────────────────────────────────────────────────────┘
↓
┌────────────────────────────────────────────────────────────────────────┐
│ 3. PUBBLICAZIONE │
│ La voce CVE viene pubblicata su cve.org │
│ Include descrizione, riferimenti e prodotti interessati │
└────────────────────────────────────────────────────────────────────────┘
↓
┌────────────────────────────────────────────────────────────────────────┐
│ 4. INTEGRAZIONE DEI DATI NVD │
│ La NVD aggiunge punteggio CVSS, corrispondenze CPE e categoria CWE │
│ La vulnerabilità compare negli strumenti di scansione automatica │
└────────────────────────────────────────────────────────────────────────┘
↓
┌────────────────────────────────────────────────────────────────────────┐
│ 5. CORREZIONE │
│ Il fornitore rilascia una patch o un aggiornamento firmware OTA │
│ La SBOM del prodotto viene aggiornata con le versioni corrette │
└────────────────────────────────────────────────────────────────────────┘
Punteggio di gravità CVSS
A ogni CVE viene assegnato un punteggio CVSS (Common Vulnerability Scoring System) che ne indica la gravità:
| Punteggio CVSS | Gravità | Esempio di impatto |
|---|---|---|
| 9,0–10,0 | Critica | Esecuzione di codice da remoto, compromissione totale del dispositivo |
| 7,0–8,9 | Elevata | Escalation dei privilegi, bypass dell’autenticazione |
| 4,0–6,9 | Media | Divulgazione di informazioni, denial of service |
| 0,1–3,9 | Bassa | Lieve fuga di informazioni, exploit teorico |
Perché i CVE sono importanti per i fabbricanti di hardware
Segnalazione delle vulnerabilità ai sensi del CRA
Il CRA crea un collegamento diretto tra il monitoraggio dei CVE e gli obblighi di legge:
| Requisito del CRA | Collegamento con i CVE |
|---|---|
| Preallarme entro 24 ore (al CSIRT coordinatore e all’ENISA) | Si attiva quando una vulnerabilità del vostro prodotto viene attivamente sfruttata |
| Nessuna vulnerabilità sfruttabile nota al momento della messa a disposizione | I CVE corrispondenti ai componenti del vostro SBOM devono essere valutati; quelli sfruttabili nel prodotto devono essere corretti prima che questo sia messo a disposizione sul mercato |
| Gestione delle vulnerabilità per il periodo di assistenza (almeno 5 anni, salvo che l’uso previsto del prodotto sia più breve) | Il monitoraggio dei CVE deve proseguire per l’intero periodo di assistenza |
| Aggiornamenti di sicurezza (ad esempio tramite OTA) | Le correzioni delle vulnerabilità sfruttabili devono raggiungere senza ritardo i dispositivi in campo |
Il collegamento SBOM–CVE
L’SBOM del vostro prodotto è la chiave per il monitoraggio automatizzato dei CVE:
| Componente della SBOM | Esempio di rischio CVE |
|---|---|
| Kernel FreeRTOS 10.4.2 | CVE-2021-31571 — integer overflow nella creazione delle code |
| mbedTLS 2.28.0 | CVE-2023-43615 — buffer overread nelle suite TLS con cifrari a flusso |
| lwIP 2.1.3 | CVE-2026-119053 — out-of-bounds read nell’agente SNMP |
| U-Boot 2023.04 | CVE-2024-57256 — sovrascrittura della memoria tramite filesystem ext4 artefatto |
| Kernel Linux 5.15 | Centinaia di CVE all’anno — monitoraggio continuo essenziale |
La pipeline automatizzata: SBOM → corrispondenza CPE → consultazione del database CVE → filtraggio per gravità → redazione della notifica CRA → distribuzione della patch OTA. Questo è ciò che fornisce il nostro servizio di monitoraggio SBOM.
Monitoraggio dei CVE per i prodotti embedded
Sfide specifiche dell’embedded/IoT
| Sfida | Descrizione |
|---|---|
| Cicli di impiego lunghi | I dispositivi IoT restano in campo per 10–15 anni; i CVE si accumulano nel tempo |
| Risorse limitate | I dispositivi possono non disporre di banda/memoria sufficienti per patch frequenti |
| Ritardo dei componenti | I fornitori embedded utilizzano spesso versioni datate di componenti open-source |
| BSP personalizzato | I Board Support Package dei fornitori di silicio possono contenere componenti non tracciati |
| Dipendenze annidate | Le dipendenze transitive (dipendenze di dipendenze) spesso non figurano nella SBOM |
| Nessun aggiornatore centralizzato | A differenza dei sistemi operativi mobili, ogni fabbricante gestisce la propria pipeline di aggiornamento |
Flusso di lavoro di monitoraggio consigliato
- Generare la SBOM in fase di build (formato SPDX o CycloneDX).
- Mappare i componenti agli identificatori CPE per la corrispondenza con il database NVD.
- Scansione continua dei CVE — controlli automatizzati giornalieri o in tempo reale rispetto ai feed NVD/EPSS.
- Triage basato sul rischio — assegnare la priorità in base al punteggio CVSS, all’EPSS (Exploit Prediction Scoring System) e all’esposizione del prodotto.
- Correggere o mitigare — distribuire le correzioni tramite aggiornamento OTA o pubblicare indicazioni di mitigazione.
- Segnalare tramite la piattaforma unica di segnalazione dell’ENISA — in caso di sfruttamento attivo, attivare il preallarme entro 24 ore, la notifica entro 72 ore e il rapporto finale.
Termini correlati
- SBOM — L’inventario dei componenti che consente la corrispondenza automatizzata dei CVE.
- ENISA — L’agenzia dell’UE che gestisce la piattaforma unica di segnalazione per le notifiche di vulnerabilità del CRA.
- CRA — Il regolamento che richiede la gestione delle vulnerabilità, per la quale il monitoraggio dei CVE è una pratica fondamentale.
- Aggiornamento OTA — Il meccanismo di distribuzione delle patch di sicurezza attivate dai CVE.
Riferimenti ufficiali
- CVE Program — MITRE Corporation — MITRE (database CVE e autorità di numerazione)
- National Vulnerability Database (NVD) — NIST (dati CVE arricchiti con punteggi CVSS)