Remediation automatizzata delle vulnerabilità, dal rilevamento alla correzione

Che cosa significa remediation automatizzata delle vulnerabilità

La remediation delle vulnerabilità consiste nell'eliminare una vulnerabilità nota dal Suo software: aggiornare il pacchetto interessato, applicare una patch o sostituire il componente. La remediation automatizzata affida al software la parte meccanica di questo lavoro. Legge un rilevamento, individua la versione che lo corregge, modifica il manifest, il lockfile o il codice e propone la modifica, il più delle volte come pull request.

Per le dipendenze di terze parti, dove si concentra la maggior parte delle vulnerabilità note di una codebase moderna, il ciclo è lo stesso in ogni strumento:

1. Inventario. Sapere quali pacchetti, in quali versioni, si trovano in tutto ciò che distribuisce.
2. Confronto. Confrontare l'inventario con gli advisory e continuare a farlo man mano che ne vengono pubblicati di nuovi.
3. Priorità. Decidere che cosa correggere per primo, in base a gravità, sfruttamento ed esposizione.
4. Correzione. Scegliere la versione corretta, aggiornarla e adattare il codice se l'aggiornamento rompe qualcosa.
5. Verifica. Compilare e testare la modifica, poi confermare che la versione corretta sia quella effettivamente distribuita.
6. Registrazione. Conservare una traccia di che cosa è stato interessato, quando è stato corretto e in quale release.

L'automazione è più forte nei passaggi 2, 4 e 6, dove il lavoro è ripetitivo. È più debole dove gli input sono sbagliati, e l'input di tutto il resto è il passaggio 1.

Quattro tipi di remediation automatizzata

Approccio	Che cosa fa	Esempi	Dove si ferma
Bot di aggiornamento delle dipendenze	Aprono pull request che portano una dipendenza vulnerabile a una versione corretta	Dependabot security updates, Renovate	Si basano su manifest e lockfile del repository; un aggiornamento con breaking change richiede comunque una persona per adattare il codice
Pull request di correzione degli strumenti SCA	Aprono pull request di aggiornamento per i rilevamenti di uno strumento SCA commerciale	Snyk, Black Duck, Aikido, Endor Labs	La copertura varia: alcuni strumenti correggono solo le dipendenze dirette, altri aggiungono patch o backport
Correzioni del codice con l'IA	Generano una modifica al codice per un rilevamento, spesso un alert di analisi statica	GitHub Copilot Autofix	Suggerimenti non deterministici che richiedono revisione; veda la remediation con l'IA
Remediation automatica dell'infrastruttura	Annulla una configurazione errata o applica una patch a un host quando scatta una regola	Strumenti di cloud security posture ed endpoint	Copre l'infrastruttura in esecuzione, non le dipendenze all'interno del software che distribuisce

I primi tre correggono tutti il codice che Lei distribuisce e condividono tutti un presupposto: che l'elenco di pacchetti vulnerabili da correggere sia quello giusto.

Ogni correzione dipende dall'inventario

Uno strumento di remediation può correggere solo le vulnerabilità che conosce, e conosce quelle contenute nel suo inventario. La maggior parte degli inventari viene ricostruita dai file: manifest, lockfile, pacchetti installati o un'immagine container finita. Questa ricostruzione tralascia elementi in modi prevedibili.

• Pacchetti che i file non dichiarano. Gli strumenti scaricati dalla build, le immagini base, i plugin e tutto ciò che viene installato da uno script non compaiono mai in un lockfile, quindi per loro non viene mai aperta una pull request di correzione.
• Versioni diverse dal lockfile. La build può risolvere una versione diversa da quella letta da uno scanner, soprattutto senza un lockfile sottoposto a commit. Una correzione basata sulla versione sbagliata è una risposta sbagliata data con sicurezza.
• Pacchetti ripristinati dalle cache. Una dipendenza in cache non torna più al registry, quindi ciò che la build ha usato può restare indietro rispetto a ciò che dice il repository.

La soluzione è partire da ciò che la build ha effettivamente usato. Una SBOM di build viene registrata durante l'esecuzione della build, quindi elenca i pacchetti scaricati dal job, compresi quelli transitivi, anziché ciò di cui un manifest dice di aver bisogno. La remediation che parte da lì corregge ciò che viene distribuito.

Che cosa automatizzare e che cosa no

La maggior parte dei team per cui la remediation funziona la suddivide così:

• Automatizzi il rilevamento e il confronto. Nuovi advisory vengono pubblicati ogni giorno. Ricontrollare a mano ogni build distribuita rispetto a questi advisory non scala, ed è esattamente il tipo di lavoro che il software fa bene.
• Automatizzi la proposta. Scegliere la versione corretta e aprire la modifica è un lavoro meccanico. Raggruppi gli aggiornamenti correlati, così i revisori vedono una pull request invece di venti.
• Subordini il merge ai test. Esegua il merge automatico degli aggiornamenti di sicurezza a livello di patch coperti dalla suite di test. Lasci a una persona gli aggiornamenti con breaking change e tutto ciò che non ha copertura di test.
• Lasci alle persone le decisioni che richiedono giudizio. Se una vulnerabilità interessi davvero il Suo prodotto, e se questa settimana valga la pena fare un aggiornamento rischioso, sono decisioni. Le registri, ad esempio come dichiarazione VEX, così la stessa domanda non viene posta due volte.

Come valutare uno strumento di remediation

Prima di affidare a uno strumento l'apertura di pull request sui Suoi repository, chieda:

1. Da dove proviene il suo elenco di vulnerabilità: dai file nel repository, da un'immagine scansionata o dalla build stessa?
2. Corregge le dipendenze transitive o solo quelle dirette che Lei dichiara?
3. Come sceglie la versione corretta: la versione minima con patch, l'ultima o una versione che Lei fissa?
4. La correzione viene compilata e testata prima che Lei la veda, oppure la pull request è la prima volta che viene eseguita?
5. Può raggruppare e pianificare gli aggiornamenti, così da non sommergere i revisori?
6. Registra quali release sono state interessate e quando è stata distribuita ogni correzione?

Il ruolo di CRACI oggi

CRACI esegue i Suoi job GitHub Actions sui propri runner e registra i pacchetti che ogni job ha effettivamente scaricato, comprese le dipendenze transitive e i pacchetti ripristinati dalle cache, con uno stato di completezza per ogni job. Questa registrazione è l'inventario da cui dovrebbe partire un workflow di remediation.

CRACI rivaluta continuamente le SBOM monitorate, così quando viene pubblicato un nuovo advisory Lei vede quali build distribuite interessa nei Suoi repository. I team di sicurezza esaminano ogni rilevamento e lo inviano al team responsabile della correzione, e CRACI supporta VEX per registrare in che modo una vulnerabilità interessa il Suo prodotto. La SBOM della build successiva mostra poi se la versione corretta è quella realmente usata dalla build. La pagina sul tracciamento delle vulnerabilità illustra la funzionalità completa.

Ai sensi del Cyber Resilience Act dell'UE, i fabbricanti devono affrontare e correggere le vulnerabilità senza ritardo, anche tramite aggiornamenti di sicurezza. Un registro di ciò che ogni build conteneva e di quando è stata distribuita ogni correzione è l'evidenza di cui quel processo ha bisogno.

Remediation automatizzata delle vulnerabilità: domande frequenti

Che cos'è la remediation automatizzata delle vulnerabilità?

La remediation automatizzata delle vulnerabilità è un software che trasforma un rilevamento in una correzione senza che una persona debba fare il lavoro manuale: individua la versione corretta, modifica il manifest, il lockfile o il codice e propone la modifica, di solito come pull request. Una persona, o una policy di cui il team si fida, decide comunque che cosa passa al merge.

Qual è la differenza tra remediation e mitigazione delle vulnerabilità?

La remediation elimina la vulnerabilità, ad esempio aggiornando a una versione corretta o applicando una patch. La mitigazione riduce il rischio mentre la vulnerabilità è ancora presente, ad esempio disattivando la funzionalità interessata o bloccando il percorso di attacco. La mitigazione fa guadagnare tempo; la remediation chiude il rilevamento.

La remediation delle vulnerabilità può essere completamente automatizzata?

In parte sì. Trovare le build interessate, confrontare gli advisory e proporre un aggiornamento di versione sono attività meccaniche e si automatizzano bene. Decidere se un aggiornamento con breaking change è sicuro, o se una vulnerabilità interessa davvero il Suo prodotto, richiede ancora giudizio. La maggior parte dei team automatizza la proposta e lascia il merge a una persona, supportata dai test.

Dependabot esegue la remediation automatizzata delle vulnerabilità?

I Dependabot security updates aprono pull request che aggiornano una dipendenza vulnerabile alla versione minima con patch, per gli alert che GitHub genera sul grafo delle dipendenze del Suo repository. È remediation automatizzata per ciò che manifest e lockfile dichiarano. CRACI vs Dependabot spiega dove ciò che è dichiarato e ciò che è distribuito divergono.

Che cosa dovrei cercare in uno strumento di remediation delle vulnerabilità?

Da dove proviene il suo elenco di vulnerabilità, se gestisce le dipendenze transitive, come sceglie la versione di correzione, se la correzione viene compilata e testata prima che Lei la veda e se registra che cosa è stato corretto e quando. L'ultimo punto conta per gli audit e per il CRA, che chiede ai fabbricanti di correggere le vulnerabilità senza ritardo.