Remediation delle vulnerabilità con l'IA: che cosa possono fare le pull request di correzione

Che cos'è la remediation con l'IA

La remediation delle vulnerabilità con l'IA usa un modello linguistico per produrre la correzione di una vulnerabilità nota. Si presenta in tre forme:

• Suggerimenti di correzione del codice. Un modello propone una patch accanto a un avviso dell'analisi statica. GitHub Copilot Autofix, per esempio, "genera automaticamente suggerimenti di modifica del codice per gli avvisi CodeQL rilevati nelle pull request e sul branch predefinito".
• Aggiornamenti delle dipendenze che adattano il codice. Alzare una versione è facile. La parte difficile è la funzione rinominata o il valore predefinito cambiato che la nuova versione porta con sé. Un modello può apportare queste modifiche conseguenti nella stessa pull request.
• Remediation agentica. Un agente porta avanti da solo la correzione in più passaggi: modifica il codice, esegue la build e i test, legge gli errori, riprova e apre una pull request solo quando i controlli passano.

Dove le correzioni IA valgono la spesa

I bot di aggiornamento basati su regole aprono già pull request che portano un pacchetto vulnerabile a una versione corretta. Si bloccano quando l'aggiornamento rompe qualcosa, perché adattare il codice chiamante non è una regola. È lì che si accumula il backlog: l'aggiornamento di sicurezza che resta aperto per mesi perché nessuno ha il tempo di affrontare il cambio di versione major.

Leggere un changelog, trovare i punti di chiamata e riscriverli è il tipo di lavoro che i modelli linguistici fanno bene. Una correzione IA che arriva con l'aggiornamento e le modifiche al codice, già compilata e testata, trasforma una settimana di attenzione di qualcuno in una revisione.

Dove le correzioni IA sbagliano

Le descrizioni più chiare dei limiti arrivano dai vendor stessi. A proposito di Copilot Autofix, GitHub scrive:

• "Usa un modello generativo non deterministico. Anche con lo stesso avviso e lo stesso codice, potrebbe non riuscire a produrre un suggerimento valido, oppure il suggerimento potrebbe variare da un tentativo all'altro."
• "Il sistema non sa quali versioni delle dipendenze siano supportate o sicure, e potrebbe suggerire dipendenze inventate pubblicate con nomi statisticamente probabili."

Il secondo punto non è ipotetico. Le ricerche sui modelli che generano codice hanno misurato quanto spesso raccomandano pacchetti che non esistono: nomi che un attaccante può registrare e riempire di malware. Una correzione che installa un pacchetto inventato dal modello sostituisce una vulnerabilità con una peggiore.

Tre misure di protezione coprono la maggior parte del rischio:

1. Compilare e testare ogni correzione prima che una persona la revisioni, così il tempo di revisione va alle correzioni che funzionano.
2. Verificare ogni pacchetto aggiunto o modificato rispetto al registry e alla versione attesa.
3. Lasciare il merge a una persona. Una correzione IA è la pull request di un contributore, non una decisione.

Spazzatura in ingresso, pull request in uscita

Uno strumento di remediation con l'IA corregge le vulnerabilità che gli vengono indicate. Se quell'elenco è ricostruito da lockfile o da un'immagine scansionata, eredita ogni lacuna della ricostruzione: strumenti scaricati dalla build che nessun manifest dichiara, versioni diverse da quelle che la build ha risolto, pacchetti ripristinati dalle cache. Lo strumento apre allora pull request sicure di sé per alcune vulnerabilità e di altre non viene mai a sapere.

Alcuni team si spingono oltre e chiedono a un modello di ricavare le dipendenze da solo. Così anche l'inventario diventa non deterministico, ed è proprio l'unica parte del processo che dovrebbe dare sempre lo stesso risultato. SBOM generate dall'IA spiega perché un inventario ipotizzato non è un'evidenza.

Lo schema che funziona prevede dati deterministici alla base e il giudizio dell'IA sopra: un elenco registrato di ciò che ogni build contiene davvero, confrontato con gli advisory tramite ricerca, e l'IA che scrive la correzione.

Dove si colloca CRACI

CRACI è il livello deterministico. 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. Rivaluta continuamente le SBOM monitorate, così un nuovo advisory compare accanto alle build che interessa, e i team di sicurezza esaminano ogni rilevamento e lo inoltrano al team responsabile della correzione.

È l'elenco da cui una correzione IA dovrebbe partire e, dopo il merge della correzione, la SBOM della build successiva mostra se la versione corretta è quella che la build ha davvero usato. Consulti il monitoraggio delle vulnerabilità per la funzionalità completa e IA e sicurezza deterministica a confronto per capire dove si colloca ciascun approccio.

Remediation delle vulnerabilità con l'IA: domande frequenti

Che cos'è la remediation delle vulnerabilità con l'IA?

La remediation delle vulnerabilità con l'IA usa un modello linguistico per produrre la correzione di una vulnerabilità: una modifica al codice per un rilevamento dell'analisi statica, oppure l'aggiornamento di una dipendenza insieme alle modifiche al codice che l'aggiornamento richiede. Il risultato è di solito un suggerimento o una pull request che una persona deve revisionare.

Che cos'è la remediation agentica?

La remediation agentica fornisce a un agente IA gli strumenti per portare avanti da solo una correzione in più passaggi: leggere il rilevamento, modificare il codice, eseguire build e test e ripetere finché non passano, quindi aprire una pull request. La differenza rispetto a un singolo suggerimento è che l'agente verifica il proprio lavoro prima che una persona lo veda.

Le correzioni di sicurezza generate dall'IA si possono unire senza rischi?

Le tratti come la pull request di qualsiasi altro contributore. GitHub descrive Copilot Autofix come non deterministico e avverte che potrebbe suggerire dipendenze inventate: revisioni quindi la modifica, esegua i test e verifichi che ogni pacchetto aggiunto esista e sia quello che si aspetta.

L'IA può trovare le vulnerabilità nelle dipendenze?

Per questa parte è lo strumento sbagliato. Stabilire se la versione di un pacchetto è interessata da un advisory noto è una semplice ricerca, e il risultato dovrebbe essere sempre lo stesso. Lasci che strumenti deterministici producano l'elenco dei pacchetti vulnerabili a partire da una SBOM registrata e usi l'IA dove il giudizio aiuta: scrivere e adattare la correzione.

Di che cosa ha bisogno uno strumento di remediation con l'IA per funzionare bene?

Di un elenco accurato di ciò che è effettivamente vulnerabile, di una build e di una suite di test su cui verificare la correzione e di una persona che decida il merge. Il primo è quello che manca più spesso: una pull request di correzione per un pacchetto che il prodotto non distribuisce è rumore, e un pacchetto vulnerabile sfuggito all'inventario non ne riceverà mai una.