Un team trascorre l'intero sprint a correggere una vulnerabilità CVSS 9.8, trovata nascosta in una libreria che nessun ambiente di produzione utilizza mai. Nel frattempo, una vulnerabilità CVSS 6.5, presente su un endpoint accessibile da Internet, rimane aperta per un altro mese perché non è mai stata inserita in cima alla lista delle priorità. Non si tratta di un'ipotesi, ma del risultato predefinito di una prioritizzazione delle vulnerabilità basata esclusivamente sul punteggio di gravità, un errore più comune di quanto la maggior parte dei programmi di sicurezza sia disposta ad ammettere.
Che cosa dovrebbe effettivamente fare la prioritizzazione delle vulnerabilità?
La prioritizzazione delle vulnerabilità è il processo che decide quali vulnerabilità correggere per prime, da un elenco che è quasi sempre troppo lungo per essere completato interamente. Se eseguita correttamente, risponde a una domanda più specifica e complessa rispetto a "quanto è grave questa vulnerabilità in teoria": risponde a "quanto la correzione di questa vulnerabilità, ora, riduce effettivamente il rischio per questo specifico sistema". Non si tratta della stessa domanda, e confonderle è l'errore che commettono la maggior parte dei processi di prioritizzazione delle vulnerabilità.
Perché il punteggio di gravità da solo non basta
Il CVSS non è mai stato concepito per essere un sistema di prioritizzazione completo a sé stante, è un punteggio di gravità, una descrizione di quanto grave potrebbe essere teoricamente una vulnerabilità in un contesto generico. Non dice nulla su:
- Reperibilità. Non è chiaro se il percorso di codice vulnerabile venga effettivamente richiamato in qualche punto dell'applicazione, oppure se rimanga inutilizzato in una dipendenza che non viene invocata da nulla.
- Sfruttabilità. Se esista un exploit funzionante nella pratica o se la vulnerabilità sia solo teorica e non verificabile in un ambiente di laboratorio.
- Esposizione. Sia che il componente interessato sia esposto a Internet, sia che si trovi tre livelli dietro un servizio interno senza accesso esterno.
- Contesto aziendale. Sia che il sistema interessato gestisca dati dei clienti o flussi di pagamento, sia che si tratti di un semplice strumento interno di scarso valore su cui nessuno fa affidamento.
Un approccio alla prioritizzazione delle vulnerabilità che si basa esclusivamente sul punteggio CVSS considera una vulnerabilità con punteggio 9.8 in un codice irraggiungibile più urgente di una con punteggio 6.5 in un percorso accessibile da Internet e con un exploit noto. Tale classificazione è errata ed è la diretta conseguenza del valutare la gravità ignorando tutti gli altri fattori che determinano il rischio effettivo.
Il costo nascosto di una prioritizzazione errata delle vulnerabilità
Il costo non si limita alle ore di lavoro sprecate dagli ingegneri, sebbene anche questo sia un dato di fatto: i team dedicano regolarmente tempo e risorse a individuare vulnerabilità di elevata gravità che non comportano alcun rischio pratico, mentre problemi realmente sfruttabili rimangono aperti. Il costo più subdolo è la fiducia. Quando gli sviluppatori vengono ripetutamente distolti dal loro lavoro principale per correggere vulnerabilità che si rivelano irraggiungibili o già mitigate altrove, iniziano a sottovalutare anche il prossimo avviso, e l'intero scopo della prioritizzazione delle vulnerabilità, ovvero risolvere prima le cose giuste, smette silenziosamente di essere attuato, anche se tecnicamente l'elenco viene completato in ordine.
Cosa richiede realmente una buona prioritizzazione delle vulnerabilità
Una prioritizzazione efficace delle vulnerabilità sovrappone diversi segnali alla gravità, anziché sostituirla completamente:
- Analisi di raggiungibilità. Verificare che la funzione vulnerabile venga effettivamente chiamata dal codice dell'applicazione e non sia semplicemente presente nell'albero delle dipendenze.
- Sfruttare la disponibilità. Verifica se esiste un exploit pubblico o una campagna attiva che prende di mira la specifica vulnerabilità, e non solo la famiglia CVE.
- Eliminazione dei duplicati tra gli scanner. Lo stesso problema di fondo, segnalato da tre strumenti diversi, non dovrebbe essere considerato come tre voci separate che competono per l'attenzione.
- Contesto aziendale e di esposizione. Valutare i risultati in base a ciò che l'asset interessato effettivamente tocca, e non solo in base al punteggio generico del CVE.
- Un imbuto visibile, non un elenco piatto. La possibilità di vedere quanti risultati superano ciascun filtro, da ogni singolo problema fino a ciò che è effettivamente sfruttabile, rende la definizione delle priorità difendibile anziché una scatola nera.
Quest'ultimo punto è più importante di quanto sembri. Un elenco piatto, ordinato per gravità, non dà al team alcuna percezione della portata del problema: il 40% del backlog è reale o solo il 2%? Una visione a imbuto, che mostri prima tutti i problemi, poi quelli risolvibili, poi quelli raggiungibili, poi quelli con una vulnerabilità nota e infine quelli effettivamente sfruttabili in questo ambiente, trasforma un elenco ingestibile in uno breve e gestibile.
Cosa cercare negli strumenti di prioritizzazione delle vulnerabilità
Non tutte le piattaforme pubblicizzate come strumenti di prioritizzazione delle vulnerabilità svolgono effettivamente il lavoro descritto sopra. Quando si valutano gli strumenti di prioritizzazione delle vulnerabilità, alcune domande permettono di smascherare rapidamente le promesse di marketing:
- Indica la raggiungibilità o si limita a segnalare la presenza di un pacchetto vulnerabile?
- Il sistema elimina i duplicati dei risultati tra i diversi scanner, inclusi gli strumenti di terze parti già in uso, oppure ogni fonte aggiunge un elenco separato e non correlato?
- Un responsabile della sicurezza può visualizzare l'intero processo, quanti risultati sono stati filtrati e perché, oppure solo l'elenco finale "prioritizzato" senza alcuna visibilità sulla logica sottostante?
- Tiene conto della disponibilità di exploit derivanti da informazioni reali sulle minacce, o solo del punteggio CVSS statico pubblicato al momento della divulgazione?
- La prioritizzazione si applica in egual misura ai risultati degli scanner nativi e a quelli degli strumenti di terze parti integrati, oppure solo ai risultati del fornitore stesso?
Quest'ultima domanda è più importante di quanto sembri. Molti strumenti di prioritizzazione delle vulnerabilità danno priorità solo a ciò che hanno trovato loro stessi, lasciando tutto ciò che viene ingerito da SAST, SCA, oppure scanner di terze parti che si trovano in una pila separata, non classificata.
Come Xygeni affronta la prioritizzazione delle vulnerabilità
Quello di Xygeni ASPM Applica un imbuto a quattro fasi: acquisisce i risultati sia dagli scanner nativi che dagli strumenti di terze parti, crea una visibilità unificata sull'inventario risultante, quindi correla e assegna le priorità utilizzando la deduplicazione, l'accessibilità e il contesto basato sull'IA, prima che i risultati raggiungano la coda di uno sviluppatore. In pratica, questo imbuto restringe un elenco completo di risultati a ciò che è risolvibile, a ciò che è accessibile nel codice dell'applicazione, a ciò che ha un exploit noto e infine a ciò che è effettivamente sfruttabile in quello specifico ambiente, in modo che l'elenco su cui un team lavora effettivamente sia abbastanza piccolo da poter essere elaborato completamente, e non solo sottoposto a triage all'infinito.
Poiché questo livello di prioritizzazione delle vulnerabilità si applica ai risultati acquisiti da scanner di terze parti, nonché Gli scanner nativi di Xygeni, una squadra non deve strappare uno strumento esistente per ottenere una visione unificata e correlata. La logica di prioritizzazione si basa sui dati già presenti, colmando la lacuna lasciata aperta dalla maggior parte degli strumenti di prioritizzazione delle vulnerabilità che si limitano a classificare i propri risultati.
FAQ
Perché il CVSS da solo non è sufficiente per la prioritizzazione delle vulnerabilità?
Il CVSS misura la gravità teorica, non il rischio effettivo in un ambiente specifico. Non tiene conto del fatto che il codice vulnerabile sia raggiungibile, che esista un exploit in circolazione o di quanto sia esposto il sistema interessato, fattori che influenzano in modo sostanziale la decisione di correggere prioritariamente una vulnerabilità.
Qual è la differenza tra gravità e sfruttabilità nella prioritizzazione delle vulnerabilità?
La gravità descrive quanto dannosa potrebbe essere teoricamente una vulnerabilità. La sfruttabilità descrive se tale danno è effettivamente realizzabile al momento, dato un exploit funzionante e un percorso di codice accessibile. Una vulnerabilità di elevata gravità e bassa sfruttabilità è spesso meno urgente di una vulnerabilità di gravità moderata e altamente sfruttabile.
Gli strumenti di prioritizzazione delle vulnerabilità devono necessariamente includere anche i risultati degli scanner di terze parti?
Sì, altrimenti un team si ritrova con diverse liste di priorità separate e non correlate, una per ogni strumento, invece di una visione unificata di ciò che conta davvero di più nell'intera architettura.
In che misura l'analisi di raggiungibilità può realisticamente ridurre un elenco di risultati?
Varia a seconda del codice sorgente, ma è comune che la maggior parte delle vulnerabilità segnalate si trovino in percorsi di codice che non vengono mai effettivamente eseguiti, il che significa che la sola raggiungibilità spesso esclude una grande quantità di vulnerabilità da una seria valutazione ancor prima che venga analizzata la loro sfruttabilità.
Un elenco più ristretto e prioritario è forse un segnale che il rischio viene ignorato?
No, al contrario. Un elenco più breve, ottenuto tramite un'effettiva prioritizzazione delle vulnerabilità, significa che il rumore di fondo è stato eliminato, non il rischio. L'alternativa, un lungo elenco non filtrato che nessuno può esaminare a fondo, produce risultati peggiori perché il rischio reale si perde nella quantità.
