Come ridurre il rumore nella gestione delle vulnerabilità

Da dove nasce il rumore delle vulnerabilità

Prenda un backlog e lo ordini in base all'origine di ciascun risultato. I numeri qui sotto sono illustrativi, non un benchmark, ma le categorie sono quelle che i team trovano quando analizzano un campione del proprio backlog.

Origine del risultato	Su 1.000 risultati (illustrativo)	Passaggio che lo elimina
Componenti che non distribuisce: voci di lockfile e manifest, layer di build, strumenti di sviluppo e test	300	1. Rendere corretto l'inventario
La stessa CVE segnalata da più strumenti, o una volta per ogni repository	250	2. Contare ogni risultato una volta
Corrispondenze errate: collisioni di nomi CPE, backport delle distribuzioni	80	1. Rendere corretto l'inventario
Risultati veri che non possono essere sfruttati nel Suo prodotto	150	4. Aggiungere il contesto di sfruttabilità
Risultati veri ancora senza correzione	70	5. Una decisione di policy con scadenza
Risultati senza responsabile	50	5. Assegnare a un responsabile
Restano da classificare e correggere	100	Prioritizzazione

Una distinzione rende più semplice il resto della pagina. Alcuni di questi risultati sono falsi positivi: il risultato è sbagliato, perché il componente non c'è o la versione non è interessata. Altri sono rumore: il risultato è corretto, ma non cambia ciò che fa questa settimana. Richiedono correzioni diverse, e confonderli è il modo in cui i team finiscono per sopprimere risultati veri o discutere su quelli sbagliati.

Falso positivo: il risultato è sbagliato	Rumore: corretto, ma non urgente
Il componente non è in ciò che distribuisce	Il codice vulnerabile non può essere raggiunto o attivato nel Suo prodotto
La corrispondenza è errata: una collisione CPE, o una correzione in backport che il numero di versione nasconde	Non esiste ancora una correzione, oppure il prodotto è interno e non esposto
Si risolve correggendo l'inventario e il matching	Si risolve con il contesto, una decisione documentata e un responsabile

Passaggio 1. Far corrispondere l'inventario a ciò che distribuisce

È la leva singola più importante, perché ogni passaggio successivo moltiplica gli errori dell'inventario. Un componente elencato ma mai distribuito produce un risultato in ogni scanner, in ogni repository e in ogni release.

• Registrare dalla build. Costruisca l'inventario da ciò che la build di release ha effettivamente usato, non dai manifest o da una scansione dell'artefatto finito. Una SBOM in fase di build contiene ciò che il job ha scaricato, compreso ciò che nessun lockfile elenca.
• Identificare i componenti con i PURL. Un package URL come pkg:npm/[email protected] indica con esattezza ecosistema, pacchetto e versione. Il confronto con advisory indicizzati per PURL, come gli advisory degli ecosistemi in OSV, elimina le corrispondenze errate che nascono dal dedurre un CPE dal nome di un prodotto.
• Usare un matching consapevole della distribuzione per i pacchetti del sistema operativo. Debian e altre distribuzioni applicano in backport le correzioni di sicurezza alla versione che hanno distribuito invece di aggiornarla, quindi il numero di versione può sembrare più vecchio della correzione upstream. Confronti con il security tracker della distribuzione stessa, non con gli intervalli di versione upstream.
• Monitorare la completezza. Sappia quando l'inventario non ha potuto vedere qualcosa, invece di presumere che sia completo. Un componente mancante è peggio di uno rumoroso: non produce alcun risultato.

Esempio pratico. Il lockfile di un servizio Node.js include [email protected], una libreria di glob matching da cui dipendono gli strumenti di test e di build. Una scansione del lockfile segnala CVE-2024-4067, un denial of service tramite espressione regolare corretto nella 4.0.8. Il job di release installa solo le dipendenze di produzione, con npm ci --omit=dev, quindi micromatch non entra mai nella build distribuita. Una registrazione di quella build non lo contiene, e il risultato non arriva mai nel backlog. La CVE è reale; per questo prodotto, il risultato è un falso positivo.

Passaggio 2. Contare ogni risultato una sola volta

La stessa CVE arriva dallo strumento SCA, dallo scanner di container e dalla piattaforma SBOM, e di nuovo per ogni repository che usa la libreria. Deduplichi su un'unica chiave: package URL, versione e CVE. Per esempio, pkg:npm/[email protected] con CVE-2024-45296 è un solo risultato, indipendentemente da quanti strumenti lo segnalino.

• Conti un risultato per artefatto distribuito, non uno per scanner.
• Aggreghi tra build e repository, così la CVE di una libreria condivisa è una sola decisione applicata ovunque, non quaranta ticket.
• Consolidi gli scanner che si sovrappongono. Una regola semplice: i risultati sulle dipendenze vengono da un'unica fonte SCA o SBOM, quelli sulle immagini da un unico scanner di container, quelli sul Suo codice da un unico strumento SAST. Se due strumenti segnalano lo stesso segnale, tenga quello più vicino a ciò che viene distribuito (SAST vs SCA).

Passaggio 3. Distribuire meno

Ogni dipendenza che non distribuisce è una fonte di risultati che non dovrà mai gestire.

• Rimuova le dipendenze inutilizzate. La maggior parte dei progetti si porta dietro qualche pacchetto che nessuno importa più.
• Aggiorni il pacchetto che introduce quelli vulnerabili. Express 4.19.2 fissa [email protected] e [email protected], che portano CVE-2024-45590 e CVE-2024-45296. Non è possibile aggiornarli da soli senza override. Express 4.20.0, rilasciato a settembre 2024, dipende dalle versioni corrette, quindi un solo aggiornamento risolve entrambe (dipendenze transitive).
• Usi immagini base minimali. Le immagini slim e distroless contengono meno pacchetti del sistema operativo, quindi si applicano meno advisory. La scansione dei container tratta le leve specifiche delle immagini.
• Fissi le versioni e aggiorni in modo deliberato. Lockfile e digest rendono l'inventario stabile tra una build e l'altra.
• Blocchi le build che contengono una versione nota come vulnerabile. Un policy gate che ferma la build tiene fuori una libreria vulnerabile prima che diventi un risultato di cui qualcuno deve fare il triage.

example-service
└─ [email protected]          → upgrade to 4.20.0
   ├─ [email protected]    CVE-2024-45590
   └─ [email protected]  CVE-2024-45296

Passaggio 4. Aggiungere il contesto di sfruttabilità

Ciò che resta dopo i passaggi da 1 a 3 è reale. Il contesto decide che cosa è urgente.

• VEX. Registri "non interessato" una sola volta, con una giustificazione, come dichiarazione VEX, e la riutilizzi tra release e clienti. Quando i clienti inoltrano le proprie scansioni del Suo prodotto, gli stessi record rispondono loro: consulti come scalare un PSIRT e, per i modelli di risposta, come rispondere ai clienti dopo un attacco alla supply chain.
• La raggiungibilità, dove i Suoi strumenti la offrono, mostra se il Suo codice può chiamare la funzione vulnerabile. Aiuta, entro certi limiti (analisi di raggiungibilità).
• Segnali di sfruttamento. CISA KEV indica che una vulnerabilità viene sfruttata in the wild; EPSS stima quanto è probabile lo sfruttamento nei prossimi 30 giorni.
• Esposizione. Un prodotto esposto su internet ha la precedenza su uno strumento interno in una rete privata.

Passaggio 5. Assegnare i risultati a un responsabile, con una policy

• Scriva le soglie come policy. Imposti soglie di gravità e sfruttabilità per prodotto o repository in una policy, non come un filtro della dashboard applicato da una sola persona.
• Assegni i responsabili per repository o team, così ogni risultato ha qualcuno che decide.
• Decida esplicitamente su "nessuna correzione disponibile": accettare con una data di scadenza, mitigare o sostituire il componente. Un risultato senza correzione non dovrebbe restare aperto senza una decisione.

Gli sviluppatori ignorano i risultati per quattro motivi: nessun responsabile, nessun contesto, nessuna scadenza o il canale sbagliato. I team con cui parliamo raccontano di un engineering che spegne gli scanner perché l'output era troppo rumoroso per essere letto. Risolva ciascun motivo: un responsabile per repository, il contesto del passaggio 4 allegato, una scadenza dalla policy e la consegna dove il team lavora già.

Ridurre il rumore o nascondere il rischio

Un backlog più piccolo è migliore solo se si è ridotto per le ragioni giuste.

• Una soppressione senza motivazione e senza scadenza è un debito nascosto. Ritorna in un audit o in un incidente, quando non c'è più nessuno che ricordi perché.
• Le soglie minime di gravità nascondono i risultati sbagliati invece di eliminarli. "Niente sotto CVSS 7" fa sparire un falso positivo con CVSS 6 e ne lascia al suo posto uno con CVSS 9.
• Ogni decisione di non correggere richiede una documentazione. La chiedono i clienti, e la chiedono normative come il Cyber Resilience Act dell'UE, che si aspetta che i fabbricanti gestiscano le vulnerabilità per tutto il periodo di supporto di un prodotto.

Come misurarlo

• Risultati per release distribuita, non per scansione.
• La quota di risultati su cui si è agito: corretti, mitigati o decisi.
• Chiusi come non interessati con un record VEX, rispetto a quelli soppressi senza.
• Tempo dalla build al responsabile: quanto aspetta un nuovo risultato prima che qualcuno se ne faccia carico.
• Il tasso di duplicati tra strumenti.

Un campione di 50 risultati da analizzare in un pomeriggio. Scelga a caso 50 risultati aperti. Per ciascuno, annoti se il componente è distribuito nella release, se un altro strumento o repository segnala lo stesso risultato, se la corrispondenza è corretta, se è sfruttabile nel Suo prodotto, se esiste una correzione e chi ne è responsabile. I conteggi Le dicono da quale passaggio iniziare. Ripeta lo stesso campione un trimestre dopo. Non citiamo benchmark di settore per questi numeri, perché nessuna fonte primaria ne supporta uno.

Dove si colloca CRACI

CRACI interviene sui passaggi 1 e 2, sul gate della build nel passaggio 3 e su parte dei passaggi 4 e 5, per il software compilato in GitHub Actions.

• L'inventario. CRACI sostituisce i Suoi runner ospitati da GitHub e registra i pacchetti che ogni job ha effettivamente scaricato, con un PURL per componente e uno stato di completezza per SBOM. Ogni componente di una SBOM CRACI era nella build. Questa accuratezza riguarda i componenti della SBOM; una CVE corrispondente può comunque non riguardare il Suo prodotto. A questo serve VEX, e CRACI supporta VEX.
• Un risultato, molte build. I risultati sono aggregati tra build e repository, e le SBOM monitorate vengono rivalutate di continuo man mano che vengono pubblicate nuove vulnerabilità.
• Gate. I policy gate possono fermare una build in tempo reale in base ai risultati, anche una build che contiene una specifica CVE.
• Triage e assegnazione. I team di sicurezza fanno il triage dei risultati in CRACI e inoltrano ciascuno al team responsabile della correzione.
• Notifiche. CRACI notifica alle persone interessate una vulnerabilità e la sua gravità.

CRACI non offre analisi di raggiungibilità, SAST o dashboard MTTR. Veda il monitoraggio delle vulnerabilità per la funzionalità completa, oppure scopra che cosa contengono davvero le Sue build.

Quando CRACI non è la risposta

• La maggior parte del Suo rumore viene da risultati SAST nel Suo codice. È un problema di tuning del SAST.
• Il Suo backlog è composto soprattutto da risultati reali e sfruttabili nel codice distribuito. È un problema di capacità di remediation, non di rumore.
• Le serve il contesto runtime dei carichi di lavoro in produzione. Una CNAPP o uno strumento di sicurezza runtime risponde a questo.

Per il quadro più ampio, veda che cosa automatizzare quando il numero di CVE continua a crescere, e i dati live sui trend di pubblicazione delle CVE.

Ridurre il rumore delle vulnerabilità: domande frequenti

Come riduco il numero di alert sulle vulnerabilità?

Li tagli alla fonte, in ordine: faccia corrispondere l'inventario a ciò che distribuisce, deduplichi i risultati per package URL, versione e CVE, distribuisca meno dipendenze, aggiunga contesto di sfruttabilità come VEX, KEV ed EPSS, e assegni ciò che resta a un responsabile secondo una policy scritta. Poi stabilisca le priorità.

Perché il nostro scanner segnala migliaia di vulnerabilità, e quali contano?

Di solito perché segnala componenti che non distribuisce, riporta la stessa CVE una volta per strumento e per repository, e sbaglia alcune corrispondenze. Contano quelle nei componenti che la Sua release contiene davvero, sfruttabili nel Suo prodotto e di cui è noto o probabile lo sfruttamento.

Come deduplico i risultati di più strumenti di sicurezza?

Usi come chiave di ogni risultato il package URL, la versione e la CVE, e conti un risultato per artefatto distribuito. Aggreghi tra repository, così una libreria condivisa è una sola decisione. Poi affidi ogni tipo di segnale a un solo strumento, così due scanner smettono di segnalare la stessa cosa.

Dovremmo sopprimere le vulnerabilità che non hanno una correzione?

Non in silenzio. Prenda una decisione esplicita: accettare il rischio con una motivazione scritta e una data di scadenza, mitigarlo o sostituire il componente. Poi la riveda quando arriva una correzione. Una soppressione senza motivazione e senza scadenza è un debito nascosto.

Una vulnerabilità che nessuno ha corretto per un anno è ancora rumore?

Non necessariamente. L'età non dice nulla sul rischio. Se è distribuita ed è sfruttabile, richiede una decisione e un responsabile. Se non riguarda il Suo prodotto, lo registri come dichiarazione VEX così smette di ripresentarsi. In ogni caso, non dovrebbe restare aperta senza una decisione.

Come faccio a far sì che gli sviluppatori non ignorino i risultati di sicurezza?

Dia a ogni risultato un responsabile, il contesto per agire, una scadenza da una policy scritta, e lo consegni dove il team lavora già. Elimini prima il rumore: gli sviluppatori smettono di leggere un canale in cui la maggior parte dei risultati non conta.

Qual è un buon numero di vulnerabilità aperte?

Non esiste un benchmark affidabile, e il conteggio grezzo è la misura sbagliata. Monitori i risultati per release distribuita, la quota su cui si è agito, la quota chiusa con una motivazione documentata e per quanto tempo le vulnerabilità sfruttate note restano aperte nel software distribuito.