Prioritizzazione delle vulnerabilità: come decidere che cosa correggere prima

Perché la sola gravità non funziona

La scelta predefinita è ordinare per CVSS e scendere a partire dai critici. Sembra oggettivo, ma fallisce per tre motivi:

• CVSS misura la gravità, non il rischio. Descrive quanto sarebbe grave una vulnerabilità se sfruttata. Non dice se qualcuno la sta sfruttando, né se conta nel Suo prodotto.
• Troppe voci dell'elenco sono urgenti. Molte CVE pubblicate hanno un punteggio alto o critico, quindi una coda ordinata per CVSS mette in cima centinaia di risultati e non offre alcun modo per scegliere tra loro.
• L'elenco vale quanto l'inventario. Uno scanner che legge un lockfile segnala dipendenze di sviluppo che non vengono mai distribuite, e non vede i pacchetti che la build ha scaricato al di fuori del package manager. Entrambe le cose distorcono la classifica prima ancora che inizi.

La prioritizzazione aggiunge le domande mancanti: viene sfruttata, quanto è probabile che lo sia, e che cosa succede a Lei se lo è.

I segnali

Segnale	Domanda a cui risponde	Fonte
CVSS	Quanto è grave se sfruttata? Punteggio da 0 a 10.	FIRST (lo standard); NVD e i vendor pubblicano i punteggi
EPSS	Quanto è probabile lo sfruttamento nei prossimi 30 giorni? Una probabilità da 0 a 1.	FIRST, aggiornato ogni giorno, gratuito
CISA KEV	Viene già sfruttata in the wild?	Catalogo Known Exploited Vulnerabilities di CISA
SSVC	Dati sfruttamento, impatto e la Sua missione, che cosa dovrebbe fare: track, attend o act?	Alberi decisionali di CERT/CC e CISA
Il Suo contesto	La versione vulnerabile viene distribuita? È esposta? Quanto è importante il prodotto? Esiste una correzione?	Il Suo inventario, la Sua architettura e i Suoi registri degli asset

I segnali pubblici descrivono la vulnerabilità. Solo il Suo contesto descrive il Suo rischio, ed è la parte che la maggior parte dei team ricava dalla fonte meno affidabile.

Un metodo pratico di prioritizzazione

La maggior parte dei programmi finisce per adottare una qualche versione di questi livelli. Imposti le tempistiche in base a ciò che chiedono la Sua policy e i Suoi clienti.

1. Da correggere subito: vulnerabilità note come sfruttate, nel software che distribuisce. Tutto ciò che è nell'elenco KEV, o con altre evidenze di sfruttamento, ed è presente in una build rilasciata. A titolo di confronto, la BOD 26-04 di CISA concede alle agenzie federali statunitensi anche solo 3 giorni per una voce KEV su un sistema esposto pubblicamente.
2. Da correggere a seguire: probabile sfruttamento e gravità elevata. Un punteggio EPSS alto combinato con un CVSS alto o critico, in un componente distribuito ed esposto. Scelga una soglia EPSS che produca una coda che il Suo team riesce davvero a smaltire.
3. Da correggere in modo ordinario: tutto il resto che viene distribuito. Lo raggruppi in aggiornamenti regolari delle dipendenze invece di gestire ogni risultato come un incidente.
4. Da documentare: non interessato. Il pacchetto vulnerabile è presente ma il codice vulnerabile non viene usato, oppure il componente non viene distribuito. Registri la motivazione come dichiarazione VEX, così lo stesso risultato non torna in revisione e i clienti che lo chiedono possono vedere il perché.

Poi riordini di continuo. Una vulnerabilità rimasta al terzo livello può passare al primo da un giorno all'altro quando viene aggiunta a KEV o il suo punteggio EPSS balza in alto.

Le vulnerabilità che non arriva mai a classificare

Ogni metodo di prioritizzazione classifica i risultati che ha davanti. Un pacchetto vulnerabile che lo scanner non ha mai visto non produce alcun risultato, quindi non ottiene mai un punteggio CVSS, un punteggio EPSS o una corrispondenza KEV. Non viene classificato in basso. Non viene classificato affatto, e viene distribuito comunque.

Accade più spesso di quanto sembri, perché la maggior parte degli scanner ricava il contenuto del Suo software dai file: il lockfile, i manifest o l'output della build. Tutto ciò che la build scarica e che nessun lockfile elenca è una dipendenza nascosta, e gli strumenti basati sui file non la vedono:

• Hook di installazione. Codice scaricato dagli script npm preinstall e postinstall, la strada usata dal worm Shai-Hulud.
• Script di build. Gli script di build di Rust, ad esempio, che scaricano codice in fase di build.
• Immagini base. L'immagine base di una build di container e i suoi layer del sistema operativo.
• Cache. Pacchetti ripristinati da una cache CI invece di essere installati dal lockfile.

Scansionare l'output in seguito non colma la lacuna. Un binario finito, soprattutto codice compilato come Rust, lascia lo scanner a indovinare che cosa vi sia entrato. E poiché le build non sono riproducibili per impostazione predefinita, ricompilare lo stesso commit in seguito non garantisce le stesse dipendenze.

Una SBOM in fase di build parte dall'estremità opposta. CRACI esegue i Suoi job GitHub Actions e vede il traffico in ingresso in ogni build, quindi registra ogni pacchetto effettivamente introdotto dal job, dipendenze nascoste comprese. Ogni SBOM riporta uno stato di completezza che indica quando non è stato possibile rilevare qualcosa. In pratica, CRACI ha trovato pacchetti vulnerabili che Snyk e Aikido non avevano segnalato, perché alle loro scansioni mancavano quei componenti. Sono esattamente i risultati che un metodo di prioritizzazione non ha mai la possibilità di classificare.

Il contesto: la parte a cui gli scanner non possono dare un punteggio per Lei

La versione vulnerabile viene davvero distribuita?

È la domanda che elimina più rumore. Un framework di test in un lockfile, un pacchetto fissato in un branch che non viene mai rilasciato, una fase di container che viene scartata: nessuno di questi raggiunge i clienti. Una SBOM registrata durante la build risponde alla domanda partendo da ciò che la build di release ha effettivamente usato, e non da ciò che il repository dichiara.

Quali release la contengono, e da quando?

Un risultato in un prodotto che Lei distribuisce ai clienti, con tutte le release dalla scorsa primavera colpite, ha la precedenza sullo stesso risultato in uno strumento interno. Conoscere il periodo di esposizione Le dice anche che cosa comunicare.

Il codice vulnerabile è raggiungibile?

L'analisi di raggiungibilità verifica se il Suo codice può chiamare la funzione vulnerabile in una dipendenza. Diversi strumenti SCA la offrono, ed è efficace nello spingere verso il basso i risultati non raggiungibili. La tratti come un input tra gli altri: vede solo i percorsi di codice che l'analisi riesce a seguire, e una funzione raggiungibile non è la stessa cosa di una funzione sfruttabile.

È esposta, ed esiste una correzione?

Un servizio esposto su Internet ha la precedenza su un job batch in una rete privata. Una vulnerabilità con una versione corretta costa meno da chiudere di una che richiede una mitigazione. Entrambi i fattori cambiano l'ordine, non il fatto che venga gestita.

Gestione delle vulnerabilità basata sul rischio

La gestione delle vulnerabilità basata sul rischio è il nome, a livello di programma, della stessa idea: classificare in base a evidenze di sfruttamento, probabilità, gravità e contesto aziendale, misurare la velocità con cui si chiudono i risultati più rischiosi e accettare che quelli a basso rischio possano restare aperti. Le metriche cambiano di conseguenza. Invece del numero totale di vulnerabilità aperte, tenga traccia di quante vulnerabilità note come sfruttate sono aperte nel software distribuito, e per quanto tempo restano aperte.

Strumenti per la prioritizzazione delle vulnerabilità

Oggi la maggior parte della classificazione è svolta da tre tipi di strumenti:

• Piattaforme di gestione delle vulnerabilità dell'infrastruttura come Tenable, Qualys e Rapid7 assegnano un punteggio a host, endpoint e asset cloud con i propri rating di rischio, basati sull'intelligence sullo sfruttamento.
• Strumenti SCA e di sicurezza applicativa come Snyk, Endor Labs e Semgrep classificano i risultati sulle dipendenze, diversi dei quali con l'analisi di raggiungibilità.
• Strumenti open source come Grype, che riporta i dati EPSS e KEV insieme ai risultati, e Dependency-Track, che analizza le SBOM di continuo.

Strumenti di gestione delle vulnerabilità a confronto li esamina uno per uno.

Come CRACI supporta la prioritizzazione

CRACI parte dal punto in cui la classificazione va storta più spesso: l'inventario. Esegue i Suoi job GitHub Actions e registra i pacchetti effettivamente scaricati da ciascun job, comprese le dipendenze transitive, i pacchetti ripristinati dalle cache e le dipendenze nascoste che nessun lockfile elenca.

• Risultati per ciò che è stato distribuito. Le SBOM monitorate vengono rivalutate di continuo, e le viste dell'organizzazione aggregano i risultati di tutte le build e di tutti i repository. Ogni pacchetto mostra i suoi advisory con la gravità e i pacchetti che lo introducono.
• Periodo di esposizione. La cronologia delle build mostra quali build passate contenevano una dipendenza vulnerabile, diretta o transitiva, così Lei sa quali release sono state colpite e per quanto tempo.
• Triage e instradamento. I team di sicurezza eseguono il triage dei risultati e inviano ciascuno al team responsabile della correzione. CRACI supporta VEX per registrare che una vulnerabilità non riguarda il Suo prodotto.
• Gate. I policy gate possono bloccare una build in base ai risultati, anche una build che contiene una specifica CVE.

CRACI non offre l'analisi di raggiungibilità. Se è il segnale che Le serve di più, scelga uno degli strumenti SCA che la offrono. Veda il monitoraggio delle vulnerabilità per la funzionalità completa.

Prioritizzazione delle vulnerabilità: domande frequenti

Che cos'è la prioritizzazione delle vulnerabilità?

La prioritizzazione delle vulnerabilità consiste nel decidere quali vulnerabilità note correggere per prime, quali possono aspettare e quali non La riguardano affatto. Classifica i risultati in base alla probabilità che vengano sfruttati e ai danni che ciò causerebbe nel Suo ambiente, non solo in base alla gravità.

Come si dà priorità alle vulnerabilità?

Parta da un inventario accurato, così da classificare le vulnerabilità del software effettivamente distribuito. Metta per primo tutto ciò che è nell'elenco Known Exploited Vulnerabilities di CISA, poi classifichi il resto per probabilità di sfruttamento (EPSS) e gravità (CVSS), adattandole al Suo contesto: esposizione, importanza del prodotto ed esistenza di una correzione. Registri come dichiarazioni VEX quelle che non La riguardano.

CVSS basta per dare priorità alle vulnerabilità?

No. CVSS misura quanto è grave una vulnerabilità, non quanto è probabile che venga sfruttata né quanto conta per Lei. Classificare solo in base a CVSS segna come alta o critica una grande parte del backlog, e la maggior parte di quelle vulnerabilità non viene mai sfruttata.

Che cos'è la gestione delle vulnerabilità basata sul rischio?

La gestione delle vulnerabilità basata sul rischio classifica e corregge le vulnerabilità in base al rischio che rappresentano per la Sua organizzazione, combinando evidenze di sfruttamento, probabilità, gravità e contesto aziendale, invece di affrontarle per punteggio CVSS o per anzianità.

Qual è la differenza tra EPSS e KEV?

EPSS è una previsione: la probabilità stimata che una CVE venga sfruttata nei prossimi 30 giorni. KEV è un registro: il catalogo di CISA delle vulnerabilità con evidenze di sfruttamento in the wild. Una voce KEV è un fatto; un punteggio EPSS è una probabilità. Usi prima KEV, poi EPSS per classificare tutto il resto.

L'analisi di raggiungibilità sostituisce la prioritizzazione?

No, è un input in più. La raggiungibilità verifica se il Suo codice può chiamare la funzione vulnerabile in una dipendenza. Elimina i risultati che non possono essere attivati, ma non dice nulla sulla probabilità di sfruttamento e copre solo il codice che l'analisi riesce a seguire.