Remediation delle CVE: dall'advisory a una build corretta e distribuita

Il processo di remediation delle CVE

La remediation delle CVE elimina una vulnerabilità divulgata pubblicamente dal software che Lei utilizza o distribuisce. Per il Suo codice significa una patch. Per le dipendenze open source, da cui proviene la maggior parte delle CVE in un prodotto tipico, significa arrivare a una versione in cui la vulnerabilità è corretta. In entrambi i casi i passaggi sono gli stessi:

1. Trovare ogni prodotto, build e release che contiene il pacchetto e la versione interessati.
2. Valutare se la vulnerabilità La riguarda e quanto gravemente.
3. Dare priorità rispetto a tutto il resto ancora aperto.
4. Correggere con un aggiornamento, una patch, una sostituzione o, se non esiste una correzione, una mitigazione.
5. Verificare che la versione corretta sia quella effettivamente contenuta nella nuova build.
6. Registrare che cosa è stato interessato, che cosa ha deciso e quando è stata distribuita la correzione.

Passaggio 1: trovare ogni build interessata

La prima domanda dopo un advisory è dove si trova il pacchetto. Rispondere partendo dai repository sorgente è lento e spesso sbagliato: la versione in un lockfile, quella risolta da una build e quella in un'immagine container rilasciata possono essere tutte diverse. Le dipendenze transitive e i pacchetti che una build scarica al di fuori del package manager non compaiono affatto nei manifest.

La risposta affidabile viene da una SBOM di ogni release, confrontata continuamente con gli advisory. Se quella SBOM è registrata durante la build, elenca ciò che la build ha effettivamente usato, quindi il confronto Le dice quali build distribuite contengono la versione vulnerabile, non quali repository la citano.

Passaggio 2: dare priorità in base a gravità e sfruttamento

La sola gravità classifica come urgenti troppe vulnerabilità. La maggior parte dei team combina tre segnali:

Segnale	Che cosa indica	Pubblicato da
CVSS	Quanto è grave la vulnerabilità se sfruttata, con un punteggio da 0 a 10	FIRST (lo standard); NVD e i vendor pubblicano i punteggi
EPSS	La probabilità stimata di sfruttamento nei prossimi 30 giorni	FIRST
KEV	Se è noto che la vulnerabilità viene sfruttata in the wild	Il catalogo Known Exploited Vulnerabilities di CISA

Aggiunga poi il Suo contesto: se il pacchetto interessato viene distribuito ai clienti o gira solo in un job di test, e se la funzione vulnerabile viene usata. Una vulnerabilità nota come sfruttata in un pacchetto distribuito va in cima alla lista. La prioritizzazione delle vulnerabilità trasforma questi segnali in un metodo.

Tempistiche di remediation

• CISA BOD 26-04. Dal 10 giugno 2026, le agenzie federali statunitensi fissano ogni scadenza in base a quattro domande: se l'asset è esposto pubblicamente, se la vulnerabilità è nel catalogo KEV, se lo sfruttamento può essere automatizzato e se dà un controllo parziale o totale. Le risposte vanno da 3 giorni, con triage forense per i casi peggiori, alla correzione al successivo aggiornamento del sistema. Ha sostituito la BOD 22-01, che concedeva due settimane per la maggior parte delle voci KEV.
• Cyber Resilience Act dell'UE. I fabbricanti devono affrontare e correggere le vulnerabilità senza ritardo, anche tramite aggiornamenti di sicurezza (allegato I, parte II). Dall'11 settembre 2026, una vulnerabilità attivamente sfruttata in un prodotto fa scattare anche un obbligo di segnalazione: un preallarme entro 24 ore, una notifica entro 72 ore e una relazione finale entro 14 giorni dalla disponibilità di una correzione.
• La Sua policy. La maggior parte dei programmi di sicurezza fissa obiettivi interni per gravità. Qualunque essi siano, può rispettarli solo se il passaggio 1 è rapido.

Passaggio 3: scegliere la correzione

Opzione	Quando usarla
Aggiornare	Esiste una versione corretta. Preferisca l'aggiornamento più piccolo che include la correzione, per limitare i breaking change.
Aggiornare il pacchetto padre	Il pacchetto vulnerabile è transitivo. Una release più recente della dipendenza diretta spesso porta con sé la correzione.
Override	Il pacchetto padre non ha rilasciato una correzione. Forzi la versione transitiva con npm overrides, Yarn resolutions o pnpm.overrides, e la testi.
Patch o backport	Non può ancora passare alla versione major corretta. Applichi la correzione upstream alla versione che usa.
Sostituire	Il pacchetto non è più mantenuto o continua a produrre CVE. Passi a un'alternativa.
Mitigare e documentare	Non esiste ancora una correzione, oppure il Suo prodotto non è interessato. Riduca l'esposizione e registri la valutazione, ad esempio come dichiarazione VEX.

Gran parte di questo passaggio può essere automatizzata, dalla scelta della versione all'apertura della pull request. La remediation automatizzata delle vulnerabilità spiega che cosa automatizzare e che cosa lasciare a una persona.

Passaggio 4: una correzione unita non è una correzione distribuita

La pull request è stata unita, quindi la CVE è chiusa. Non necessariamente. La correzione è nel repository, ma una build ripristina una cache obsoleta, un'immagine base contiene ancora il vecchio pacchetto o un branch di release non ha mai recepito la modifica. Il ticket risulta corretto mentre il prodotto distribuisce ancora la versione vulnerabile.

Chiuda il cerchio dall'altra estremità: controlli la SBOM della build successiva e confermi che la versione vulnerabile è sparita. Quando quella SBOM registra ciò che la build ha effettivamente scaricato, compresi i pacchetti ripristinati dalle cache, il controllo risponde alla domanda che cliente, auditor e autorità di regolamentazione stanno davvero ponendo.

Come CRACI supporta la remediation delle CVE

• Trovare. CRACI registra i pacchetti scaricati da ogni job GitHub Actions, comprese le dipendenze transitive e i pacchetti ripristinati dalle cache, e rivaluta continuamente le SBOM monitorate. Le viste a livello di organizzazione aggregano i rilevamenti tra build e repository, così vede quali build sono interessate da una nuova CVE.
• Assegnare. I team di sicurezza esaminano ogni rilevamento e lo inviano al team responsabile della correzione. CRACI supporta VEX per registrare in che modo una vulnerabilità interessa il Suo prodotto.
• Verificare. Ogni nuova build ottiene la propria SBOM con uno stato di completezza, così può confermare che la versione corretta è quella usata dalla build.
• Segnalare. Per le vulnerabilità attivamente sfruttate ai sensi del CRA, CRACI invia le notifiche alle autorità per conto del fabbricante.

Veda il tracciamento delle vulnerabilità per la funzionalità completa.

Remediation delle CVE: domande frequenti

Che cos'è la remediation delle CVE?

La remediation delle CVE consiste nell'eliminare una vulnerabilità divulgata pubblicamente, identificata dal suo ID CVE, dal software che Lei utilizza o distribuisce. Per una dipendenza di solito significa aggiornare a una versione in cui la vulnerabilità è corretta. Per il Suo codice significa applicare una patch.

Come stabilisco quali CVE correggere per prime?

Combini la gravità con le prove di sfruttamento. CVSS descrive quanto è grave una vulnerabilità, EPSS stima la probabilità che venga sfruttata nei prossimi 30 giorni e il catalogo Known Exploited Vulnerabilities di CISA elenca quelle già sfruttate. Una vulnerabilità nota come sfruttata in un pacchetto che distribuisce va in cima alla lista.

In quanto tempo vanno corrette le CVE?

Dipende da chi lo chiede. La Binding Operational Directive 26-04 di CISA concede alle agenzie federali statunitensi da 3 giorni fino al successivo aggiornamento del sistema, a seconda che la vulnerabilità sia nel catalogo KEV, che l'asset sia esposto pubblicamente, che lo sfruttamento possa essere automatizzato e di quanto controllo dia a un attaccante. Il Cyber Resilience Act dell'UE chiede ai fabbricanti di correggere le vulnerabilità senza ritardo, e dall'11 settembre 2026 una vulnerabilità attivamente sfruttata in un prodotto fa scattare un obbligo di segnalazione entro 24 ore.

E se non esiste ancora una versione corretta?

Mitighi e documenti. Se possibile, disattivi la funzionalità interessata, blocchi il percorso di attacco o sostituisca il componente, e registri la Sua valutazione, ad esempio come dichiarazione VEX. Poi tenga d'occhio la release corretta ed esegua la remediation quando arriva.

Come si corregge una CVE in una dipendenza transitiva?

Provi prima ad aggiornare la dipendenza diretta che la porta con sé, perché una release più recente spesso include la correzione. Se non ne esiste ancora una, la maggior parte dei package manager permette di forzare la versione di un pacchetto transitivo: overrides in npm, resolutions in Yarn, pnpm.overrides in pnpm. Testi il risultato, perché il pacchetto padre non è stato compilato con quella versione.