Articolo Pubblicazioni

Vulnerability management: dare priorità con CVSS, EPSS e catalogo KEV

di · Pubblicato il 14 novembre 2026

Abstract

Ogni anno vengono pubblicate decine di migliaia di vulnerabilità, e nessuna organizzazione può correggerle tutte subito. L’articolo spiega perché il solo punteggio CVSS porta a priorità sbagliate, come aiutano la probabilità di sfruttamento calcolata da EPSS e il catalogo KEV delle vulnerabilità sfruttate, come si aggiunge il contesto dell’organizzazione e come si organizza un processo con tempi e metriche.

Vincenzo Calabrò | Vulnerability management: dare priorità con CVSS, EPSS e catalogo KEV
 

Troppe vulnerabilità

Un’organizzazione media trova migliaia di vulnerabilità a ogni scansione. Se il criterio è correggere tutte quelle con punteggio alto o critico, la coda non si svuota mai e il personale smette di prenderla sul serio. Solo una piccola parte delle vulnerabilità pubblicate viene effettivamente sfruttata dagli attaccanti, e il problema è riconoscerla in tempo.

Che cosa misura il CVSS

Il Common Vulnerability Scoring System, giunto alla versione 4.0, misura la gravità tecnica di una vulnerabilità, cioè quanto è facile sfruttarla e quanto danno può fare, su una scala da 0 a 10. È utile, ma non dice se qualcuno la sta sfruttando né quanto conta il sistema colpito nell’organizzazione. Il punteggio base pubblicato nei database è uguale per tutti, mentre le metriche ambientali e di minaccia, che lo adatterebbero al contesto, vengono usate raramente.

EPSS e KEV

L’Exploit Prediction Scoring System, gestito dal FIRST, stima ogni giorno la probabilità che una vulnerabilità venga sfruttata nei trenta giorni successivi, sulla base di dati osservati e delle caratteristiche della vulnerabilità. Il catalogo Known Exploited Vulnerabilities, pubblicato dall’agenzia statunitense CISA, elenca le vulnerabilità per cui esistono prove di sfruttamento reale. I due strumenti rispondono alla domanda che il CVSS lascia aperta. Una vulnerabilità nel catalogo KEV va trattata come urgente qualunque sia il suo punteggio, e una con EPSS alto va esaminata presto anche se il CVSS è medio.

Il contesto

  • Esposizione, cioè se il sistema è raggiungibile da internet, dalla rete interna o solo localmente;
  • Criticità dell’asset, in base ai processi che supporta e ai dati che contiene, ricavata dalla business impact analysis;
  • Controlli compensativi, come segmentazione, regole del firewall applicativo o funzionalità disattivate, che riducono la possibilità di sfruttamento;
  • Ruolo nella catena di attacco, perché una vulnerabilità su un controller di dominio o su un sistema di gestione remota apre la strada a tutto il resto.

Un processo con tempi

Un modo pratico è definire poche classi di priorità con tempi massimi di intervento. Per esempio, entro pochi giorni per le vulnerabilità nel catalogo KEV o con EPSS elevato su sistemi esposti a internet, entro trenta giorni per quelle gravi su sistemi critici interni, entro il ciclo ordinario di aggiornamento per le altre. Il modello SSVC, proposto dalla CISA, offre un albero di decisione già pronto per arrivare allo stesso risultato. Le eccezioni, cioè le vulnerabilità che non si possono correggere nei tempi, vanno approvate con una data di scadenza e un controllo compensativo.
Le metriche da seguire sono il tempo medio di correzione per classe, la percentuale di vulnerabilità KEV aperte oltre il termine e la copertura dell’inventario, perché le vulnerabilità sui sistemi che nessuno conosce non compaiono in nessuna scansione.

Un confronto concreto

Si considerino tre vulnerabilità trovate nella stessa scansione. La prima ha un punteggio CVSS di 9,8, riguarda un componente installato su un server interno non raggiungibile dall’esterno, ha una probabilità EPSS molto bassa e non compare nel catalogo KEV. La seconda ha un CVSS di 7,5, riguarda la VPN esposta a internet ed è nel catalogo KEV perché sfruttata in campagne di ransomware. La terza ha un CVSS di 6,1, riguarda un’applicazione web interna e ha un EPSS medio. Con il solo CVSS la prima andrebbe corretta per prima. Con il contesto la priorità è la seconda, da correggere entro pochi giorni, mentre la prima può seguire il ciclo ordinario con un controllo di segmentazione.

Il ciclo completo

  1. Inventario, con l’elenco di asset, software e versioni, collegato alla criticità dei servizi;
  2. Rilevamento, con scansioni autenticate periodiche, agenti sugli endpoint, controllo delle immagini dei container e segnalazioni dei fornitori;
  3. Valutazione, combinando gravità, probabilità di sfruttamento, catalogo KEV ed esposizione;
  4. Correzione, con patch, aggiornamenti di configurazione o misure compensative, provate prima in un ambiente di test quando i sistemi sono critici;
  5. Verifica, con una nuova scansione che conferma la chiusura;
  6. Rendicontazione, con le metriche per classe di priorità e le eccezioni aperte.

Errori ricorrenti

Il più comune è affidarsi alle scansioni non autenticate, che vedono solo una parte delle vulnerabilità e producono molti falsi positivi. Un altro è dimenticare i dispositivi che non ricevono gli aggiornamenti dal sistema centrale, come apparati di rete, stampanti, sistemi industriali e appliance dei fornitori, che sono spesso proprio quelli sfruttati negli attacchi. Un terzo è considerare chiusa una vulnerabilità quando è stata assegnata una patch, senza verificare che sia stata installata davvero. Infine molte organizzazioni non tengono traccia delle eccezioni, che diventano permanenti senza che nessuno abbia deciso di accettare il rischio.
Per un’organizzazione piccola, senza strumenti dedicati, un buon punto di partenza è controllare ogni settimana il catalogo KEV rispetto ai prodotti usati, in particolare VPN, firewall, posta e software esposti a internet, e applicare subito gli aggiornamenti corrispondenti. Questa sola abitudine copre una parte rilevante delle vulnerabilità sfruttate negli attacchi reali. Quando l’organizzazione cresce, il passo successivo è uno strumento di scansione autenticata e un inventario aggiornato, che permettono di applicare in modo sistematico le priorità descritte sopra.
 
 
Vincenzo Calabrò | Ingegnere informatico specializzato in sicurezza informatica e investigazioni digitali. Funzionario informatico del Ministero dell'Interno; su incarico autorizzato si occupa di sicurezza informatica e di perizie informatiche forensi. Autore di articoli e saggi. Lecturer, Speaker, Trainer.
Profili: Google Scholar · ORCID · ResearchGate · Academia.edu · CyberSecurity360 · AgendaDigitale · ICT Security Magazine · LinkedIn