La prioritizzazione delle vulnerabilità basata sul rischio consiste nel classificare le vulnerabilità di sicurezza in base al rischio effettivo che rappresentano per l'applicazione, anziché in base al punteggio di gravità assegnato. Questa distinzione è importante perché la gravità è una proprietà della vulnerabilità in astratto, mentre il rischio è una proprietà della vulnerabilità nel codice: se la funzione vulnerabile viene mai chiamata, se qualcuno la sta sfruttando, quanto è esposto il servizio interessato e quanto sarebbe difficile risolverlo. Una vulnerabilità CVSS 9.8 in una dipendenza che l'applicazione non utilizza mai ha una priorità inferiore rispetto a una vulnerabilità 6.1 su un endpoint esposto a Internet con un exploit pubblico. La gravità non può fornire questa informazione. La prioritizzazione basata sul rischio è l'insieme di segnali che invece può farlo.
Che cos'è la prioritizzazione delle vulnerabilità basata sul rischio? Una definizione operativa #
Ogni scansione effettuata produce più risultati di quanti il team sia in grado di risolvere. Non si tratta di un problema legato agli strumenti, ma di una questione di pura matematica: la copertura aumenta ogni anno, ma il personale rimane invariato. La domanda non è più "cosa abbiamo trovato?", ma "cosa facciamo lunedì?".
Il triage basato sulla gravità risponde male a questa domanda. Ordina i problemi in base a un numero calcolato senza alcuna conoscenza del sistema in uso, il che significa che dà priorità a una catastrofe teorica rispetto a una reale. I team lo imparano in fretta e reagiscono ignorando l'elenco, che è il peggior risultato possibile perché i tre problemi più importanti erano inclusi.
Quindi la definizione operativa è: La prioritizzazione delle vulnerabilità basata sul rischio è la pratica di ordinare i risultati utilizzando segnali contestuali relativi a sfruttabilità, raggiungibilità, esposizione e costi di ripristino, in modo che la cima della coda rifletta ciò che un attaccante potrebbe effettivamente fare a questo sistema, piuttosto che ciò che un organismo di valutazione ha giudicato possibile in generale.
Il cambiamento consiste nel passare da una proprietà della vulnerabilità a una proprietà della vulnerabilità più la tua applicazione. Stesso CVE, priorità diversa, a seconda di dove risiede.
Significato della prioritizzazione della vulnerabilità basata sul rischio, in quattro segnali #
Il modo più chiaro per comprendere il significato della prioritizzazione delle vulnerabilità basata sul rischio è quello di esaminare cosa viene aggiunto alla gravità, perché la gravità stessa non scompare. Diventa semplicemente uno dei tanti fattori di input.
- raggiungibilità. La funzione vulnerabile viene effettivamente chiamata dal tuo codice? Un pacchetto vulnerabile non è un'applicazione vulnerabile. L'analisi di raggiungibilità traccia il percorso di chiamata e lo mostra, trasformando "abbiamo 400 criticità di dipendenza" in un elenco molto più breve di quelle effettivamente eseguite.
- Sfruttabilità. Qualcuno sta sfruttando questa vulnerabilità nel mondo reale? EPS stima la probabilità di sfruttamento nei prossimi 30 giorni, il CISUn catalogo di vulnerabilità note e sfruttate registra ciò che è già in uso in natura e la disponibilità pubblica di exploit ti dice quanto lavoro dovrebbe fare un attaccante. Queste sono le prospettive dell'attaccante e cambiano quotidianamente mentre un CVSS Il punteggio rimane invariato dal giorno in cui è stato assegnato.
- Contesto aziendale. Quanto è esposto il bene interessato e qual è la sua funzione? Un servizio di pagamento accessibile via internet e uno strumento di reporting interno che rilevano lo stesso problema non comportano lo stesso rischio, e solo la vostra organizzazione sa quale dei due sia quale.
- Costo della bonifica. Quanto è difficile la correzione e cosa si rompe se la si applica? Un banale aggiornamento di patch e un importante aggiornamento di versione che interrompe la compilazione sono due cose diverse.cise una priorità che ignora lo sforzo produce una coda attorno alla quale nessuno può pianificare uno sprint.
Nel complesso, la prioritizzazione delle vulnerabilità basata sul rischio è il significato su cui la maggior parte dei team converge: Smettiamola di chiederci quanto grave potrebbe essere la situazione, cominciamo a chiederci quanto sia grave qui e quanto costi porvi fine.
Basato sulla gravità vs. basato sul rischio: quali cambiamenti #
In un modello basato sul rischio, la gravità non scompare. Diventa semplicemente uno dei tanti input, e gli altri input sono quelli che forniscono informazioni sulla tua applicazione.
| Dimensioni | In base alla gravità | Basato sul rischio |
|---|---|---|
| Segnale primario | Punteggio CVSS | Raggiungibilità, sfruttabilità, esposizione, costi fissi |
| Domanda a cui risponde | Quanto è grave questa vulnerabilità in generale? | Che cosa può fare un attaccante a questo sistema? |
| Contesto utilizzato | Nona | Il tuo codice, la tua implementazione, la tua attività |
| Uscita tipica | Una lunga lista ordinata per numero | Un breve elenco ordinato per conseguenza |
| Effetti sugli sviluppatori | Affaticamento da allerta, elenco ignorato | Meno multe, ognuna giustificata. |
| Cosa manca | Indipendentemente dal fatto che il codice venga mai eseguito. | Niente, se i segnali sono cablati correttamente |
La differenza pratica emerge nella comunicazione tra sicurezza e ingegneria. Un ticket classificato in base alla gravità dice "questo è critico, risolvilo". Un ticket classificato in base al rischio dice "questo problema è raggiungibile dal controller di checkout, esiste un exploit pubblico e la soluzione è un aggiornamento di patch". Solo uno di questi due tipi di ticket viene gestito senza discussioni.
Questa è ora la posizione ufficiale, non solo una buona prassi. #
La prioritizzazione delle vulnerabilità basata sul rischio, un tempo considerata l'alternativa più sofisticata all'applicazione delle patch in base alla gravità, sta diventando la prassi standard.
SSVC, sviluppato dal Software Engineering Institute della Carnegie Mellon e adottato da CISA, sostituisce il punteggio con un decisalbero ionico che produce un'azione anziché un numero, in base allo stato di sfruttamento, all'automatizzazione, all'impatto tecnico e alla prevalenza della missione. E nel giugno 2026 CISUn emesso Direttiva Operativa Vincolante 26-04, che sostituisce la BOD 22-01, la quale impone alle agenzie federali di dare priorità agli aggiornamenti utilizzando l'esposizione degli asset, lo stato KEV, l'automazione degli exploit e l'impatto tecnico piuttosto che la sola gravità.
Il messaggio per tutti gli altri è chiaro. L'agenzia che gestisce il catalogo ufficiale delle vulnerabilità sfruttate non impone più alle proprie agenzie di classificarle in base al CVSS. Se continuate a farlo, state utilizzando un metodo ormai superato anche da chi lo gestisce.
Come funziona un imbuto di prioritizzazione? #
I segnali di per sé non danno priorità a nulla. Devono essere concatenati, in modo che ciascuno restringa ciò che il successivo deve considerare. Questa catena è ciò che Xygeni chiama un imbuto di prioritizzazione.
Un funnel elabora i risultati attraverso un massimo di otto fasi ordinate. Quelle preconfigurate sono raggiungibilità, sfruttabilità, risolvibilità, risultato del triage AI e urgenza di risoluzione, ed è possibile aggiungere proprietà personalizzate come la criticità aziendale o l'esposizione. I funnel predefiniti coprono ogni famiglia di rischio ed è possibile filtrare qualsiasi tabella in base alla fase del funnel per visualizzare quali risultati hanno superato ciascuna fase. Una coda di diverse centinaia di risultati si riduce alla manciata di risultati reali, raggiungibili, sfruttabili e meritevoli di questo sprint.
Due di questi stadi provengono da Triage dell'intelligenza artificialePer i risultati nel tuo codice, AI Triage legge il risultato nel contesto, il flusso del codice per l'analisi statica o le prove HTTP per DAST e restituisce un verdetto di vero positivo, falso positivo o necessita di revisione, oltre a un'urgenza di correzione da Immediata a Backlog e una complessità di correzione da Facile a Difficile. Ogni risultato è accompagnato dalla motivazione, ogni output è etichettato come generato dall'IA e il tuo team può sovrascrivere qualsiasi verdetto. Per i risultati open source il design è deliberatamente diverso: non c'è un verdetto dell'IA, perché raggiungibilità Questo compito viene svolto meglio. L'IA Triage, invece, introduce urgenza e complessità.
La parte più importante per i team che dispongono già di una suite di strumenti: gli stessi funnel e lo stesso sistema di triage si applicano ai risultati acquisiti da altri scanner, non solo da quelli di Xygeni. I risultati provenienti da 40 o più strumenti e formati, inclusi gli output SARIF, vengono deduplicati e classificati nella stessa coda. Gli strumenti attualmente in uso continuano a funzionare. La prioritizzazione non è più dipendente dal singolo strumento.
L'effetto misurabile, secondo le parole di clienti che l'hanno fattoCirca il 90% di tempo in meno per identificare, dare priorità e assegnare i risultati relativi alla sicurezza presso Banco Serfinanza, su oltre 100 repository sottoposti ad analisi continua, e una riduzione del 90% del tempo di prioritizzazione delle vulnerabilità presso Fintonic.
Contatto e porta con te il tuo arretrato.
FAQ: Prioritizzazione delle vulnerabilità basata sul rischio, risposte brevi #
Ordinare le vulnerabilità di sicurezza in base a ciò che un aggressore potrebbe effettivamente fare al sistema, anziché in base al punteggio di gravità assegnato alla vulnerabilità stessa. La stessa CVE può essere urgente in un'applicazione e irrilevante in un'altra, ed è la prioritizzazione basata sul rischio che permette di distinguerle.
No, è incompleto. Il CVSS descrive la vulnerabilità; non è mai stato concepito per descrivere la tua esposizione ad essa. La prioritizzazione basata sul rischio mantiene la gravità come un indicatore e aggiunge quelli che dipendono dal tuo ambiente: se il codice è raggiungibile, se si verificano attacchi, quanto è esposta la risorsa e quanto costa la correzione.
Verifica se la funzione vulnerabile all'interno di una dipendenza viene effettivamente richiamata dalla tua applicazione. In caso contrario, la vulnerabilità è reale ma non sfruttabile tramite il tuo codice, quindi viene declassata anziché scomparire. È il filtro più importante per le vulnerabilità open source, perché la maggior parte delle vulnerabilità di dipendenza si trova in codice che non viene mai eseguito.
Dovrebbe, ed è questo il test da applicare a qualsiasi piattaforma che affermi di farlo. Una prioritizzazione che classifica solo i propri risultati lascia una coda classificata e diverse non classificate, il che non è una vera prioritizzazione. Xygeni applica gli stessi funnel e lo stesso triage basato sull'IA ai risultati acquisiti da altri strumenti.
Non conta il numero di criticità aperte. Misura il tempo che intercorre tra la segnalazione di un problema e il momento in cui viene assegnato a uno sviluppatore in grado di intervenire, la percentuale di problemi assegnati che vengono risolti anziché rimandati e il numero di ticket su cui gli sviluppatori si oppongono. La prioritizzazione basata sul rischio funziona quando le obiezioni cessano.
