Perché conta
Il security gate deve decidere cosa è “rischio alto”, e il patch management deve decidere cosa patchare prima. Entrambi si scontrano con lo stesso muro: diecimila CVE aperti, un team con tempo finito. Patchare tutto è impossibile; patchare a caso è pericoloso. Il vulnerability management è la disciplina di mettere in ordine ciò che conta — e comincia dal capire perché il punteggio che tutti usano, da solo, inganna.
Perché il solo CVSS inganna
Il CVSS misura la gravità tecnica di una vulnerabilità: quanto sarebbe grave se sfruttata. Utile, ma risponde alla domanda sbagliata se usato da solo. Un CVE con CVSS 9.8 su una libreria che non è mai esposta a input ostile, e che nessuno sta sfruttando nel mondo, è meno urgente di un CVSS 7.5 con exploit pubblico e attivo sul tuo servizio internet-facing. Ordinare la coda per solo CVSS significa lavorare sui numeri grandi, non sui rischi reali.
EPSS: la probabilità di sfruttamento
L’EPSS (Exploit Prediction Scoring System) aggiunge la dimensione mancante: la probabilità che un CVE venga sfruttato nei prossimi 30 giorni, stimata da un modello su segnali reali (exploit pubblicati, attività osservata). È un numero tra 0 e 1:
$$ \text{EPSS}(cve) = P(\text{sfruttamento entro 30 giorni}) \in [0, 1] $$
Il valore pratico di EPSS è che la stragrande maggioranza dei CVE ha probabilità bassissima di essere sfruttata: filtrare per EPSS alto riduce una coda di migliaia a una manciata di voci che meritano attenzione ora.
Comporre il rischio
Nessun punteggio singolo basta. Il rischio operativo nasce dalla composizione di gravità, probabilità ed esposizione nel tuo contesto:
$$ \text{Rischio} \approx \underbrace{\text{CVSS}}{\text{se sfruttato}} \times \underbrace{\text{EPSS}}{\text{quanto è probabile}} \times \underbrace{E}_{\text{esposizione}} $$
dove $E$ cattura il contesto che solo tu conosci: il servizio è esposto a internet? tratta dati sensibili? la funzione vulnerabile è davvero raggiungibile dal tuo codice? Una formula del genere non è una verità esatta, è un modo per ordinare la coda in modo difendibile invece che per numero grezzo.
Il segnale che batte tutto: KEV
C’è una scorciatoia che precede ogni calcolo. Se un CVE è nel catalogo CISA KEV (Known Exploited Vulnerabilities), significa che è sfruttato attivamente, ora, nel mondo reale. Questi vanno patchati per primi, sempre, indipendentemente dal CVSS:
|
|
Il ciclo, non l’evento
Il vulnerability management non è una scansione una tantum ma un ciclo: scoprire (da SCA, SBOM, scanner runtime), prioritizzare (CVSS × EPSS × contesto, con KEV in cima), rimediare (patch o mitigazione) e verificare che la correzione sia davvero in produzione. E ricominciare, perché ogni giorno arrivano CVE nuovi su software che non hai toccato. L’obiettivo non è “zero vulnerabilità” — irraggiungibile — ma tenere il rischio noto e sotto una soglia accettabile, con le decisioni tracciate.
Domanda: se prioritizzo con EPSS e raggiungibilità, non rischio di rimandare per sempre un CVSS 9.8 "non raggiungibile" che poi diventa sfruttabile dopo un mio cambio di codice?
È il rischio corretto da temere, e la risposta non è abbandonare la prioritizzazione — che è l'unica alternativa al collasso sotto diecimila CVE — ma renderla dinamica e non un giudizio dato una volta per sempre. Primo, "non raggiungibile" e "EPSS basso" non significano "ignorato": significano "declassato a debito tracciato con una finestra pianificata". Il CVE resta nell'inventario, resta visibile, e viene comunque affrontato — solo dopo ciò che è sfruttato attivamente. La differenza tra "debito pianificato" e "dimenticato" è che il primo è in una lista che qualcuno rivede. Secondo, e qui sta il punto che sollevi: la prioritizzazione va rivalutata di continuo, perché i suoi input cambiano. L'EPSS si aggiorna ogni giorno: un CVE con probabilità bassissima oggi può schizzare quando viene pubblicato un exploit, e un buon sistema di vulnerability management ri-valuta l'intera coda sui punteggi aggiornati, così quel 9.8 "dormiente" risale automaticamente in cima nel momento in cui diventa pericoloso — tipicamente prima che tu venga colpito, perché l'EPSS reagisce alla comparsa dell'exploit, non all'attacco. La comparsa nel catalogo KEV fa lo stesso in modo ancora più netto. Terzo, la raggiungibilità è una proprietà del tuo codice attuale, e hai ragione che un cambio può renderla vera: per questo la raggiungibilità si ricalcola a ogni build nella SCA, non si congela. Se una pull request inizia a chiamare la funzione prima irraggiungibile, lo stesso CVE cambia classe e il gate lo intercetta su quella PR. Quindi il meccanismo che temi — "lo rimando e mi dimentico" — è esattamente ciò che un vulnerability management fatto a ciclo impedisce: niente è giudicato una volta sola, ogni CVE è ri-pesato quando cambiano l'EPSS, il KEV o il tuo codice. La prioritizzazione non è "scegliere cosa ignorare per sempre", è "scegliere l'ordine, e rivedere l'ordine quando il mondo cambia". L'unica vera alternativa — trattare tutti i diecimila CVE come ugualmente urgenti — garantisce che il team si bruci sui 9.8 teorici mentre il 7.5 con exploit attivo aspetta il suo turno in fondo a una lista ordinata per numero. Quello sì che è dimenticare ciò che conta.
Conclusione
Il vulnerability management mette ordine nel caos dei CVE: il CVSS misura la gravità ma inganna da solo, l’EPSS aggiunge la probabilità di sfruttamento, il contesto aggiunge l’esposizione, e il catalogo KEV batte ogni calcolo. È un ciclo che ri-pesa tutto quando cambia il mondo, non un giudizio una tantum. Questo dipende dal sapere cosa succede — le fonti di segnale. Portare i log e la detection dentro la pipeline e il runtime è il prossimo capitolo.