Passa al contenuto
Inovasense

CVE

CVE (Common Vulnerabilities and Exposures) è lo standard globale per l'identificazione delle vulnerabilità di cibersicurezza, a ciascuna delle quali viene assegnato un CVE-ID univoco.

Definizione
CVE (Common Vulnerabilities and Exposures) è lo standard globale per l'identificazione delle vulnerabilità di cibersicurezza, a ciascuna delle quali viene assegnato un CVE-ID univoco.

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

DettaglioInformazione
Denominazione completaCommon Vulnerabilities and Exposures
Gestito daMITRE Corporation (USA, finanziata da CISA)
Formato dell’IDCVE-AAAA-NNNNN (anno + numero sequenziale)
Totale CVE pubblicatiOltre 300.000 (a inizio 2026)
Nuovi CVE all’anno~40.000 nel 2024, ~48.000 nel 2025 (in accelerazione)
Database pubblicocve.org
Database di arricchimentoNVD (National Vulnerability Database) — aggiunge punteggi CVSS, corrispondenze CPE
Equivalente UEL’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 CVSSGravitàEsempio di impatto
9,0–10,0CriticaEsecuzione di codice da remoto, compromissione totale del dispositivo
7,0–8,9ElevataEscalation dei privilegi, bypass dell’autenticazione
4,0–6,9MediaDivulgazione di informazioni, denial of service
0,1–3,9BassaLieve 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 CRACollegamento 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 disposizioneI 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 SBOMEsempio di rischio CVE
Kernel FreeRTOS 10.4.2CVE-2021-31571 — integer overflow nella creazione delle code
mbedTLS 2.28.0CVE-2023-43615 — buffer overread nelle suite TLS con cifrari a flusso
lwIP 2.1.3CVE-2026-119053 — out-of-bounds read nell’agente SNMP
U-Boot 2023.04CVE-2024-57256 — sovrascrittura della memoria tramite filesystem ext4 artefatto
Kernel Linux 5.15Centinaia 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

SfidaDescrizione
Cicli di impiego lunghiI dispositivi IoT restano in campo per 10–15 anni; i CVE si accumulano nel tempo
Risorse limitateI dispositivi possono non disporre di banda/memoria sufficienti per patch frequenti
Ritardo dei componentiI fornitori embedded utilizzano spesso versioni datate di componenti open-source
BSP personalizzatoI Board Support Package dei fornitori di silicio possono contenere componenti non tracciati
Dipendenze annidateLe dipendenze transitive (dipendenze di dipendenze) spesso non figurano nella SBOM
Nessun aggiornatore centralizzatoA differenza dei sistemi operativi mobili, ogni fabbricante gestisce la propria pipeline di aggiornamento

Flusso di lavoro di monitoraggio consigliato

  1. Generare la SBOM in fase di build (formato SPDX o CycloneDX).
  2. Mappare i componenti agli identificatori CPE per la corrispondenza con il database NVD.
  3. Scansione continua dei CVE — controlli automatizzati giornalieri o in tempo reale rispetto ai feed NVD/EPSS.
  4. Triage basato sul rischio — assegnare la priorità in base al punteggio CVSS, all’EPSS (Exploit Prediction Scoring System) e all’esposizione del prodotto.
  5. Correggere o mitigare — distribuire le correzioni tramite aggiornamento OTA o pubblicare indicazioni di mitigazione.
  6. 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