Oltre il CVSS: come prioritizzare le vulnerabilità con EPSS, CISA KEV e contesto dell’asset

Chi gestisce un programma di vulnerability management e deve prioritizzare le vulnerabilità conosce bene la scena: la scansione si chiude con migliaia di risultati, centinaia dei quali classificati come “critical” o “high”. Il volume non è un’impressione: nel 2026, al 2 novembre, le nuove CVE pubblicate sono in media circa 270 al giorno. A quel ritmo, l’idea di correggere tutto ciò che supera una certa soglia CVSS smette di essere una strategia e diventa una lista di arretrati.

Il tema è tornato al centro del dibattito con la BOD 26-04 di CISA, emessa il 10 giugno 2026. Con questa direttiva l’agenzia statunitense ha chiesto alle amministrazioni federali di abbandonare il patching guidato dalla sola severità per un modello basato sul rischio reale, con scadenze pienamente applicabili dal 7 dicembre 2026. La direttiva vincola solo le agenzie federali, ma la domanda che pone riguarda qualsiasi organizzazione: su quali informazioni si decide che cosa correggere per primo?

La risposta proposta qui è operativa: tre segnali, ciascuno con una funzione precisa, e un modo per combinarli in una coda di intervento che il team IT possa davvero seguire.

Prioritizzazione delle vulnerabilità: perché il CVSS da solo non basta

Il Common Vulnerability Scoring System misura la gravità tecnica di una vulnerabilità: quanto è facile sfruttarla in teoria e quali danni può causare. È un’informazione utile, ma risponde a una domanda diversa da quella che interessa a chi deve pianificare la remediation. Il punteggio base non dice se esiste un exploit in circolazione, se qualcuno lo sta già usando, né se il sistema vulnerabile è un server esposto su Internet o una macchina di laboratorio isolata.

La versione 4.0 dello standard ha dato più rilievo alle metriche di minaccia e di ambiente proprio per colmare questa distanza. Nella pratica, però, la maggior parte delle console e dei report continua a mostrare il solo punteggio base. Il risultato è una distribuzione schiacciata verso l’alto, in cui troppe vulnerabilità sembrano urgenti e quindi nessuna lo è davvero.

Per prioritizzare le vulnerabilità e uscire da questa trappola servono tre domande distinte: quanto è probabile che la vulnerabilità venga sfruttata, se è già sfruttata e quanto conta l’asset su cui si trova.

EPSS: stimare la probabilità di sfruttamento

L’Exploit Prediction Scoring System, gestito da FIRST, stima la probabilità che una vulnerabilità pubblica venga sfruttata nei trenta giorni successivi. Non sostituisce il CVSS: lo affianca, aggiungendo la dimensione che il punteggio di gravità non considera. Il modello, giunto alla versione 5 nel giugno 2026, ricalcola ogni giorno i punteggi. Questi sono liberamente consultabili tramite API o file CSV, quindi possono arricchire gli export di qualsiasi scanner senza costi di licenza.

Per usarlo bene occorre distinguere i due valori che restituisce. Il punteggio è una probabilità; il percentile indica la posizione rispetto a tutte le altre CVE. Nei dati di inizio novembre 2026, un EPSS pari a 0,10 corrisponde a circa il percentile 96. Significa una probabilità stimata di sfruttamento del 10% e un punteggio pari o superiore a quello del 96% circa delle vulnerabilità valutate. Confondere percentile e probabilità porta a sovrastimare il rischio di molte vulnerabilità che, in assoluto, hanno probabilità molto basse.

EPSS ha anche limiti che è bene dichiarare. È un modello statistico addestrato su dati di sfruttamento raccolti da terzi, quindi dipende dalla qualità e dalla disponibilità di quei dati. Si basa inoltre sugli identificativi CVE: non dice nulla sugli zero-day, sulle vulnerabilità prive di CVE e sui difetti di configurazione. Va trattato come un segnale di probabilità, non come un verdetto.

Cataloghi KEV: quando lo sfruttamento è già documentato

Il catalogo Known Exploited Vulnerabilities di CISA raccoglie le vulnerabilità per cui esistono prove di sfruttamento in attacchi reali. È un elenco volutamente selettivo: nel 2025 le nuove voci sono state in media circa venti al mese, e circa 28 al mese nei primi dieci mesi del 2026. Proprio per questo funziona meglio come un cancello che come un punteggio. Se una CVE presente nel perimetro aziendale compare nel KEV, la discussione non riguarda più se intervenire, ma con quale urgenza.

Per le organizzazioni europee esiste un riferimento analogo. ENISA, insieme alla rete dei CSIRT, mantiene un EU KEV Catalogue dedicato alle vulnerabilità sfruttate in attacchi contro soggetti dell’Unione, sincronizzato con lo European Vulnerability Database previsto dalla direttiva NIS2. Lo stesso EUVD, come dichiara ENISA, incorpora anche i dati del catalogo CISA. Più che due fonti indipendenti, le due liste vanno considerate complementari: quella europea è utile soprattutto per intercettare le vulnerabilità sfruttate contro organizzazioni dell’Unione.

Un limite comune a tutti i cataloghi KEV è il ritardo. Una vulnerabilità entra nell’elenco quando le prove di sfruttamento sono state raccolte e verificate, quindi l’assenza dal KEV non equivale a una garanzia. È qui che EPSS e KEV si completano: il primo anticipa, il secondo conferma.

Il contesto dell’asset: l’informazione che nessun feed fornisce

Probabilità e prove di sfruttamento descrivono la vulnerabilità. Il rischio, però, dipende anche da dove si trova. La BOD 26-04 lo rende esplicito: oltre alla presenza nel KEV, le scadenze dipendono dall’esposizione del sistema a Internet e dalla possibilità di sfruttare la falla in modo automatizzato. Conta anche il livello di controllo, parziale o totale, che l’attaccante otterrebbe. Sono fattori che riprendono in larga parte il modello decisionale SSVC (Stakeholder-Specific Vulnerability Categorization) già proposto da CISA, e sono facilmente replicabili in qualsiasi azienda.

A questi conviene aggiungerne altri due, che dipendono solo dall’organizzazione. Il primo è la criticità di business dell’asset: un server che gestisce l’autenticazione o la produzione pesa più di una postazione di test. Questa informazione dovrebbe derivare dall’analisi di impatto già svolta per la continuità operativa. Il secondo sono i controlli compensativi: segmentazione, autenticazione a più fattori, EDR e regole di accesso possono ridurre in modo concreto la sfruttabilità di una vulnerabilità anche prima della patch.

Nessuno di questi elementi è disponibile in un feed pubblico. Va costruito, mantenuto aggiornato nell’inventario degli asset e collegato ai risultati delle scansioni. È il passaggio più faticoso ed è anche quello che fa la differenza.

Una coda di remediation in quattro livelli

Combinando i tre segnali si ottiene una coda di intervento più corta e più difendibile. Le tempistiche vanno definite internamente, in base alle risorse disponibili, ma la logica può essere questa:

1. Intervento immediato: vulnerabilità presenti nei cataloghi KEV su asset esposti o critici, in particolare se consentono il controllo totale del sistema. Oltre alla correzione, va verificato se lo sfruttamento sia già avvenuto prima della patch.
2. Breve termine: vulnerabilità KEV su asset interni non critici e vulnerabilità con EPSS elevato su asset esposti a Internet.
3. Ciclo ordinario: vulnerabilità con CVSS alto ma EPSS basso su asset importanti. Rientrano nella normale finestra di aggiornamento, con eventuali mitigazioni nel frattempo.
4. Pianificazione o rischio accettato: tutto il resto, con una decisione documentata quando la correzione non è sostenibile nel breve periodo.

La soglia che separa un EPSS “elevato” da uno “basso” non è universale. Va tarata sul volume di risultati che il team è in grado di gestire e rivista periodicamente: una soglia troppo bassa ricrea la coda infinita, una troppo alta lascia fuori vulnerabilità che verranno sfruttate.

Dalla teoria al processo: come rendere la coda sostenibile

Il modello funziona solo se diventa un processo ripetibile. In concreto significa arricchire automaticamente i risultati dello scanner con i punteggi EPSS e con lo stato KEV, scaricabili ogni giorno in formato JSON o CSV. Vanno poi incrociati con le etichette dell’inventario degli asset: esposizione, criticità, responsabile. Poiché EPSS e KEV cambiano di continuo, la priorità va ricalcolata a ogni ciclo e non fissata una volta per tutte: una vulnerabilità da “ciclo ordinario” può passare a “intervento immediato” da un giorno all’altro.

C’è poi un aspetto spesso trascurato: tracciare le decisioni. Per ogni vulnerabilità rinviata o accettata conviene registrare il motivo, chi ha deciso e quando la scelta verrà rivista. Con il recepimento della NIS2 in Italia, la gestione delle vulnerabilità rientra tra le misure richieste ai soggetti coinvolti. La misura ID.RA-08 della determinazione ACN n. 379907 del 19 dicembre 2025 prevede che le vulnerabilità siano prontamente risolte o mitigate, ove possibile, oppure accettate documentando il rischio nel piano di trattamento. Dimostrare perché si è corretto prima una cosa e poi un’altra diventa quindi parte dell’accountability.

Quello che i punteggi non vedono

Esiste infine un’area che nessuno dei segnali descritti copre. La stessa CISA, presentando la BOD 26-04, ha riconosciuto che gli attaccanti compromettono di rado le reti interne con le sole vulnerabilità di prodotto e si affidano spesso a configurazioni sfruttabili e credenziali valide. Condivisioni esposte, deleghe eccessive in Active Directory, password deboli o servizi dimenticati non hanno un CVE, un punteggio EPSS né una voce nel KEV, eppure sono spesso il primo anello di una catena d’attacco.

Per questo la prioritizzazione automatica non sostituisce l’analisi. Un vulnerability assessment deve andare oltre l’export dello scanner: verificare i risultati, collocarli nel contesto degli asset e indagare ciò che gli strumenti non classificano. È il presupposto perché la coda di remediation rifletta il rischio reale e non solo quello che è facile misurare.

Perché conta

CVSS, EPSS e KEV rispondono a domande diverse e nessuno, da solo, basta a decidere. Il CVSS dice quanto è grave una vulnerabilità, EPSS quanto è probabile che venga sfruttata, il KEV se sta già accadendo; il contesto dell’asset dice se tutto questo riguarda davvero l’organizzazione. Prioritizzare le vulnerabilità con questi elementi non riduce il numero di quelle scoperte, ma riduce quelle che restano aperte nel posto sbagliato. Ed è su queste, non sul totale, che si misura l’efficacia di un programma di vulnerability management.

Contenuto realizzato in collaborazione con Nexsys.