Il Regolamento sulla ciberresilienza dell'UE (Regolamento (UE) 2024/2847) impone ai fabbricanti di classificare le vulnerabilità, correggere nei tempi appropriati e segnalare lo sfruttamento attivo quando ne vengono a conoscenza. Il dovere di segnalazione dell'Articolo 14 si applica dall'11 settembre 2026; gli obblighi di gestione, rimediazione e divulgazione delle vulnerabilità previsti dall'Articolo 13 e dall'Allegato I si applicano dall'11 dicembre 2027. Il Regolamento non nomina CVSS, EPSS, KEV né alcun altro sistema di scoring. Questa pagina illustra cosa misura ciascun segnale, come combinarli in una prioritizzazione difendibile e come lo scoring supporta la segnalazione delle vulnerabilità e la divulgazione coordinata delle vulnerabilità.
Sintesi
- Il Regolamento sulla ciberresilienza non impone alcun sistema di scoring. Richiede rimediazione tempestiva, ma lascia ai fabbricanti la misurazione operativa.
- CVSS misura la gravità intrinseca su una scala da 0 a 10: caratteristiche della vulnerabilità indipendenti dall'osservazione di sfruttamento in circolazione.
- EPSS misura la probabilità di sfruttamento su una scala da 0 a 1: probabilità di sfruttamento osservato nei successivi 30 giorni, calcolata dal FIRST EPSS Special Interest Group.
- CISA KEV è un segnale binario di sfruttamento attivo che può informare le decisioni di segnalazione, anche se il trigger CRA è più ampio della sola inclusione nel KEV.
- CVSS, EPSS e KEV combinati offrono una matrice di prioritizzazione difendibile; nessun segnale singolo è sufficiente da solo.
- I trigger di segnalazione sono fattuali, non determinati dai punteggi. Lo sfruttamento attivo e gli incidenti gravi sono determinati ai sensi delle definizioni giuridiche, con i punteggi come prove a supporto.
I quattro segnali che inquadrano le decisioni di gravità CRA: gravità intrinseca, probabilità di sfruttamento, orologio di segnalazione e la data in cui il dovere di segnalazione si applica.
Cosa dice il Regolamento sulla ciberresilienza riguardo allo scoring
Leggendo direttamente il regolamento non si trova alcuna menzione di CVSS, EPSS o di qualsiasi altro sistema di punteggio nominato. Gli obblighi operativi sono più semplici: il fabbricante deve avere un processo di gestione delle vulnerabilità efficace per tutto il periodo di assistenza, correggere le vulnerabilità senza indebito ritardo e pubblicare informazioni chiare sulla gravità quando è disponibile una correzione.
- Rimedio. Affrontare e correggere le vulnerabilità senza indebito ritardo, anche fornendo aggiornamenti di sicurezza.
- Informazione pubblica. Quando è disponibile un aggiornamento di sicurezza, condividere una descrizione della vulnerabilità corretta, i prodotti interessati, l'impatto probabile, la gravità e indicazioni chiare per la correzione.
Queste espressioni fissano uno standard, non un numero fisso di giorni. Sono interpretate dalle autorità di vigilanza del mercato e, in ultima istanza, dai giudici nazionali.
Lo scoring è il modo in cui i fabbricanti dimostrano tale interpretazione in audit e indagini. Un fabbricante che può mostrare una policy di gravità documentata, un sistema di tracciamento che registra CVSS ed EPSS all'ingresso, SLA collegati alle fasce di gravità e timestamp di rimediazione coerenti con tali SLA ha una posizione difendibile di «senza indebito ritardo». Chi non può farlo, non ce l'ha.
Per il regime più ampio di gestione delle vulnerabilità, vedere gestione delle vulnerabilità. Per le cadenze di segnalazione del regime di notifica degli incidenti, vedere segnalazione delle vulnerabilità.
CVSS: gravità intrinseca
Il Common Vulnerability Scoring System, mantenuto dal FIRST CVSS Special Interest Group, assegna a una vulnerabilità un punteggio da 0,0 a 10,0. È il punteggio di gravità intrinseca dominante nel settore e il punteggio che la maggior parte delle voci CVE pubblica.
CVSS v3.1 prevede tre tipi di punteggio:
| Tipo di punteggio | Cosa misura | Uso per il CRA |
|---|---|---|
| Punteggio base | Caratteristiche intrinseche della vulnerabilità: vettore di attacco, complessità, privilegi richiesti, interazione dell'utente, ambito e impatto su riservatezza, integrità e disponibilità. | Usarlo come baseline di intake perché è il punteggio pubblicato dalla maggior parte delle voci CVE. |
| Punteggio temporale | Contesto pubblico variabile nel tempo: maturità del codice di exploit, livello di rimediazione e attendibilità della segnalazione. | Usarlo quando disponibile, ma non dipenderne perché le voci CVE pubbliche lo compilano raramente. |
| Punteggio ambientale | Contesto del prodotto: criticità dell'asset, controlli compensativi, percorsi di codice raggiungibili e impatto reale del deployment. | Usarlo per documentare perché il fabbricante ha aumentato, ridotto o differito una priorità di rimediazione. |
CVSS v4.0 è stato pubblicato da FIRST il 1 novembre 2023. Mantiene i gruppi Base e Ambientale, sostituisce il gruppo Temporale di v3.1 con un gruppo Threat più ristretto, focalizzato sulla maturità dell'exploit, e aggiunge un gruppo Supplementare (che include sicurezza funzionale, automatizzabilità, recupero e densità di valore) che registra il contesto senza modificare il punteggio finale. L'adozione è graduale: molti feed CVE pubblicano ancora la v3.1 e il supporto degli strumenti per la v4.0 è disomogeneo. Si ingeriscano entrambe le versioni ove disponibili e non si tratti la transizione come una revisione della baseline del backlog.
CVSS da solo è insufficiente. La ricerca empirica mostra costantemente che la maggior parte delle vulnerabilità classificate «alta» o «critica» da CVSS non viene mai osservata come sfruttata. Una coda gestita esclusivamente da CVSS brucia capacità ingegneristica su rischi teorici mentre lo sfruttamento reale rimane senza risposta.
EPSS: probabilità di sfruttamento
L'Exploit Prediction Scoring System, anch'esso mantenuto da FIRST tramite il suo EPSS SIG, stima la probabilità che l'attività di sfruttamento contro un CVE venga osservata nei successivi 30 giorni. EPSS pubblica una probabilità tra 0 e 1 e un rango percentile rispetto a tutti i CVE.
EPSS è calcolato da un modello di machine learning che ingerisce attributi CVE (metriche CVSS, CWE, vendor e prodotto interessati, anzianità) e segnali pubblici (disponibilità di PoC, attività di sfruttamento osservata dai partner contributori, menzioni di threat intelligence). I punteggi vengono aggiornati quotidianamente. Un nuovo CVE senza PoC pubblico in genere ottiene un punteggio inferiore a 0,05; uno con un PoC weaponizzato può salire in modo significativo, in base agli altri input del modello.
Anche EPSS da solo è insufficiente. Un EPSS basso oggi non è una garanzia per il futuro: quando un ricercatore pubblica un exploit funzionante, il punteggio si muove. EPSS deve essere rivalutato continuamente, non solo al momento dell'acquisizione.
CISA KEV: sfruttamento confermato
Il catalogo Known Exploited Vulnerabilities, mantenuto dall'agenzia statunitense per la sicurezza delle infrastrutture e della cibersicurezza, è un elenco di vulnerabilità con prove affidabili di sfruttamento attivo (known exploited). Un CVE è o non è presente nel catalogo. CISA aggiunge un CVE quando dispone di prove affidabili che la vulnerabilità è stata sfruttata contro un bersaglio reale.
KEV è una fonte governativa statunitense. I fabbricanti europei lo utilizzano ampiamente grazie al suo ampio supporto negli strumenti. Dal 13 maggio 2025, ENISA gestisce anche il Database europeo delle vulnerabilità (EUVD), che pubblica lo stato di sfruttamento e una vista dedicata alle vulnerabilità sfruttate; da trattare come segnale di prioritizzazione EU aggiuntivo accanto a KEV. Entrambi sono separati dalla Piattaforma unica di segnalazione CRA (Articolo 16) e nessuno dei due è di per sé il trigger di segnalazione dell'Articolo 14.
Per il trigger di preallarme, l'inclusione nel KEV è un forte segnale che una vulnerabilità può essere «attivamente sfruttata» nel senso del regolamento. Non è l'unico segnale: il trigger è più ampio e copre qualsiasi vulnerabilità attivamente sfruttata, incluse quelle rilevate tramite segnalazioni dei clienti, telemetria interna o threat intelligence non ancora arrivata a CISA. Una vulnerabilità sfruttata contro i propri clienti ma non ancora presente nel KEV può comunque attivare il dovere. La determinazione è fattuale, non basata su elenchi, e richiede prove affidabili di sfruttamento senza autorizzazione.
Combinare CVSS, EPSS e KEV in una matrice di prioritizzazione CRA
Nessun segnale singolo è sufficiente. L'approccio difendibile consiste nel combinare tutti e tre i segnali e nel legare gli SLA di rimediazione alla fascia combinata. Il diagramma seguente illustra il motivo: un CVSS-9.8 senza sfruttamento osservato comporta un rischio reale inferiore rispetto a un CVSS-7 con EPSS 0,95 e inserimento nel KEV, anche se il primo appare peggiore in una coda basata solo su CVSS.
| Fascia | Combinazione di segnali | SLA di rimediazione | Implicazione CRA |
|---|---|---|---|
| Emergenza | Inserita nel KEV OPPURE sfruttamento attivo confermato OPPURE (CVSS Critica 9,0+ E EPSS > 0,5) | Giorni, non settimane | Revisione urgente di segnalazione se lo sfruttamento può riguardare il prodotto |
| Alta | CVSS Alta (7,0-8,9) O EPSS > 0,5 | 30 giorni | La posizione «senza indebito ritardo» è a rischio oltre 30 giorni |
| Media | CVSS Media (4,0-6,9), EPSS < 0,5, non inserita nel KEV | 90 giorni | Difendibile con documentazione e timestamp |
| Bassa | CVSS Bassa (< 4,0) | Prossimo ciclo di rilascio regolare | Documentare il rinvio nel registro di gestione delle vulnerabilità |
La matrice è la politica del fabbricante, non un requisito del Regolamento sulla ciberresilienza. Redigerla per iscritto offre a un'autorità di vigilanza del mercato una base documentata e ripetibile per le decisioni di rimediazione che potrebbe esaminare dopo che una vulnerabilità grave diventa pubblica. Una policy documentata che classifica ogni CVE all'acquisizione, registra la fascia assegnata e dimostra il rispetto dello SLA con i relativi timestamp è di gran lunga più facile da difendere rispetto a «abbiamo corretto quando ci è capitato».
La nostra analisi: una coda basata solo su CVSS sta diventando il segnale d'allarme negli audit
Le sezioni precedenti descrivono la meccanica operativa. Il riquadro che segue è la nostra lettura da professionisti, non un parere legale.
Il Regolamento attuale non nomina alcun sistema di scoring e non ci aspettiamo che lo faccia. La direzione di marcia è però chiara. Ora che l'EUVD di ENISA pubblica una vista delle vulnerabilità sfruttate accanto a CISA KEV, le evidenze orientate allo sfruttamento diventano sempre più difficili da ignorare per le autorità: «abbiamo dato priorità per CVSS e ci siamo persi quella che veniva sfruttata» è una risposta sempre meno convincente. Ci aspettiamo che le autorità di vigilanza del mercato e i CSIRT leggano un processo consapevole di EPSS e KEV come il minimo di un regime competente di gestione delle vulnerabilità, non come un'opzione avanzata. Chi costruisce già per dove sta andando l'enforcement misura la probabilità di sfruttamento, non solo la gravità.
Mappare la gravità sui trigger di segnalazione
La segnalazione non è guidata dal punteggio. Il regime di notifica degli incidenti si divide in due flussi con le stesse scadenze di 24 e 72 ore, ma con termini diversi per il rapporto finale:
- Vulnerabilità attivamente sfruttata. Notifica di preallarme entro 24 ore, notifica della vulnerabilità entro 72 ore, relazione finale entro 14 giorni dalla disponibilità di una misura correttiva o di attenuazione.
- Incidente grave. Notifica di preallarme entro 24 ore, notifica dell'incidente entro 72 ore, relazione finale entro un mese dalla notifica a 72 ore.
Nessun trigger è una soglia CVSS. «Attivamente sfruttata» è una determinazione fattuale: esistono prove affidabili che un attore malevolo abbia sfruttato la vulnerabilità senza autorizzazione. Un incidente grave è quello che può incidere negativamente sulla disponibilità, autenticità, integrità o riservatezza dei dati o delle funzioni sensibili o importanti del prodotto, oppure che può portare all'introduzione di codice maligno nel prodotto o nei sistemi e reti di informazione di un utilizzatore.
CVSS ed EPSS supportano la determinazione. Una vulnerabilità critica CVSS con EPSS > 0,9 e presenza nel KEV dovrebbe attivare una revisione urgente di segnalazione non appena vi sono prove che lo sfruttamento possa riguardare il prodotto. Non sostituiscono la determinazione. Il termine di 24 ore decorre dal momento in cui il fabbricante viene a conoscenza dello sfruttamento attivo, non dal momento in cui il punteggio CVSS supera una certa soglia numerica.
Per la cadenza completa di segnalazione, vedere segnalazione delle vulnerabilità. Per il canale di intake a monte che spesso produce il primo segnale di sfruttamento, vedere divulgazione coordinata delle vulnerabilità.
Rendere operativo lo scoring nel processo di gestione delle vulnerabilità
Un processo di scoring allineato al Regolamento sulla ciberresilienza conta sei componenti concrete:
- Acquisire CVSS al momento della scansione. La pipeline da SBOM a CVE deve allegare i Punteggi base CVSS a ogni rilevamento al primo accertamento.
- Aggiornare EPSS quotidianamente. Un job notturno che rivaluta le vulnerabilità aperte è il minimo indispensabile.
- Monitorare CISA KEV. Sottoscrivere il feed KEV e scalare automaticamente qualsiasi vulnerabilità aperta che entra nel catalogo.
- Impostare SLA per fascia nel proprio sistema di tracciamento. Le fasce e le scadenze devono essere leggibili da macchina in modo che gli elementi scaduti emergano senza triage umano.
- Escalare al superamento delle soglie. Quando EPSS supera 0,5 per un rilevamento aperto, si ri-classifichi nella fascia Alta (o Emergenza se anche CVSS è pari o superiore a 9,0). Quando KEV aggiunge uno dei propri CVE, o un cliente segnala sfruttamento attivo, l'elemento passa automaticamente alla fascia Emergenza.
- Automatizzare la mappatura SBOM-componente-CVE. La mappatura manuale si rompe su larga scala ed è la fonte più comune di vulnerabilità mancate nelle contestazioni di audit.
L'onboarding alla Piattaforma unica di segnalazione ENISA è un workstream separato ma correlato. Si consulti l'onboarding ENISA SRP.
Errori comuni
- Inseguire CVSS-9 ignorando EPSS-0.95. Una vulnerabilità CVSS-7 con EPSS 0,95 e un PoC pubblico comporta un rischio reale superiore rispetto a un CVSS-9.8 con EPSS 0,01.
- Assumere che KEV sia completo. KEV è il miglior catalogo pubblico, ma è in ritardo. Lo sfruttamento attivo contro i propri clienti può precedere l'inserimento nel KEV di giorni o settimane.
- Trattare CVSS come una scadenza. Un CVSS Critico non significa «correggere entro 24 ore». Significa «esaminare per primo». La scadenza proviene dall'SLA della propria politica, dall'EPSS, dallo stato nel KEV e, in ultima istanza, dallo standard atteso di rimediazione senza indebito ritardo.
- Non aggiornare i punteggi EPSS. Una vulnerabilità con EPSS 0,02 all'acquisizione e mai rivalutata rimane nel backlog a bassa priorità mentre lo sfruttamento reale cresce fuori dalla propria visuale.
- Ignorare i modificatori ambientali CVSS. Un Punteggio base CVSS di 9,8 contro un componente che il proprio prodotto non istanzia mai non è un 9,8 nel proprio ambiente. Si documenti il Punteggio ambientale e il ragionamento.
- Usare CVSS o EPSS come trigger di segnalazione. L'obbligo di segnalazione dipende dallo sfruttamento attivo fattuale. Un punteggio è una prova a supporto, non la determinazione.
Domande frequenti
Il Regolamento sulla ciberresilienza richiede l'uso di CVSS?
No. Il Regolamento sulla ciberresilienza non nomina CVSS né alcun altro sistema di scoring. L'obbligo di divulgazione richiede di comunicare la «gravità» quando si divulga una vulnerabilità corretta, ma non specifica la scala. CVSS è il riferimento di settore e la scala più semplice da difendere in audit. Una scala personalizzata o alternativa è ammissibile se documentata e applicata in modo coerente.
EPSS è obbligatorio ai sensi del Regolamento sulla ciberresilienza?
No. EPSS non è menzionato nel Regolamento. Aiuta a dimostrare lo standard «senza indebito ritardo», perché mostra che la prioritizzazione ha tenuto conto della probabilità di sfruttamento reale, non solo della gravità intrinseca. Un fabbricante che ignora la probabilità di sfruttamento e gestisce le patch esclusivamente per rango CVSS avrà difficoltà a giustificare a posteriori la lentezza nella rimediazione di un rilevamento con EPSS elevato.
In che modo lo scoring influisce sul contatore delle 24 ore?
Non cambia il momento in cui il contatore parte. Il contatore parte nel momento in cui il fabbricante viene a conoscenza dello sfruttamento attivo, indipendentemente da CVSS. Lo scoring aiuta a selezionare quali segnali in ingresso raggiungono la soglia di consapevolezza, ma una volta che lo sfruttamento è credibilmente accertato il contatore scorre anche se il punteggio CVSS non è ancora definitivo.
È possibile utilizzare un sistema di scoring personalizzato?
Sì, a condizione che sia difendibile in audit. Uno schema che combina il contesto del threat model interno con segnali esterni è accettabile se documentato, applicato in modo coerente e produce risultati di rimediazione allineati allo standard «senza indebito ritardo». Il riferimento di settore CVSS più EPSS più KEV è il percorso di minima resistenza perché è ampiamente riconosciuto.
Il Regolamento sulla ciberresilienza sanziona un punteggio di gravità errato?
Non direttamente. Il rischio sanzionatorio riguarda il mancato rispetto degli obblighi di gestione delle vulnerabilità o il mancato obbligo di segnalazione dello sfruttamento attivo. Un singolo punteggio errato non è automaticamente una violazione, ma un processo di scoring assente o incoerente può diventare prova che la gestione delle vulnerabilità non è stata efficace.
Si deve usare CVSS v3.1 o v4.0?
Entrambe, ove disponibili. CVSS v4.0 è stato pubblicato da FIRST il 1 novembre 2023. Mantiene i gruppi Base e Ambientale, sostituisce il gruppo Temporale con un gruppo Threat più ristretto focalizzato sulla maturità dell'exploit, e aggiunge un gruppo Supplementare (che include sicurezza funzionale, automatizzabilità, recupero e densità di valore) che registra il contesto senza modificare il punteggio. L'adozione è graduale: molti feed CVE pubblici pubblicano ancora la v3.1. Si ingeriscano entrambi i segnali ove la fonte li fornisce e non si tratti la transizione da v3.1 a v4.0 come una revisione della baseline del backlog.
Da quando si applicano questi obblighi di segnalazione?
L'Articolo 14, che contiene gli obblighi di segnalazione descritti in questa pagina, si applica dall'11 settembre 2026. Gli obblighi di gestione, rimediazione e divulgazione delle vulnerabilità previsti dall'Articolo 13 e dall'Allegato I si applicano dall'11 dicembre 2027, data in cui entra in vigore la maggior parte del Regolamento. È opportuno costruire il processo di scoring e di preparazione alla segnalazione fin d'ora, in modo che sia operativo prima del settembre 2026.
Cosa conta come «venire a conoscenza» ai fini del contatore delle 24 ore?
Il contatore di preallarme delle 24 ore parte nel momento in cui il fabbricante viene a conoscenza di una vulnerabilità attivamente sfruttata. Questo significa avere la conoscenza credibile che un attore malevolo abbia sfruttato la vulnerabilità contro un bersaglio reale: non è sufficiente una segnalazione privata di vulnerabilità né un proof-of-concept funzionante da soli. Un punteggio CVSS o EPSS non avvia il contatore; lo fa la determinazione fattuale dello sfruttamento attivo.
Come si usa l'EUVD di ENISA accanto a CISA KEV?
Dal 13 maggio 2025, ENISA gestisce il Database europeo delle vulnerabilità (EUVD), che pubblica lo stato di sfruttamento e una vista dedicata alle vulnerabilità sfruttate. Da usare come segnale di prioritizzazione accanto a CISA KEV. Nessuno dei due cataloghi è il trigger di segnalazione dell'Articolo 14 e entrambi sono separati dalla Piattaforma unica di segnalazione CRA prevista dall'Articolo 16.
Il VEX modifica la gravità o gli obblighi di segnalazione CRA?
No. Un documento VEX (Vulnerability Exploitability eXchange) non modifica il trigger di segnalazione né la gravità intrinseca di una vulnerabilità. È un modo machine-readable per registrare se il proprio prodotto è effettivamente interessato da una vulnerabilità nota (interessato, non interessato, in fase di analisi o corretto) accanto all'SBOM. Costituisce una prova a supporto per un abbassamento ambientale del punteggio o per un rinvio documentato.
Si dovrebbe usare SSVC al posto di una matrice CVSS?
È possibile. SSVC (Stakeholder-Specific Vulnerability Categorization), pubblicato da CISA con il SEI della Carnegie Mellon, è un'alternativa a decision-tree che raggiunge una decisione di rimediazione (Track, Track*, Attend, Act) a partire da input come stato di sfruttamento, esposizione e impatto sulla missione. Il CRA non lo richiede. È un framework riconosciuto e difendibile per chi preferisce un albero decisionale alla matrice CVSS più EPSS più KEV presentata in questa pagina.