Come Far Trovare all'AI Vulnerabilità Reali nel Codice Senza Tonnellate di Falsi Positivi

Se hai mai provato a puntare un LLM sul codice sorgente con un prompt "trova vulnerabilità", probabilmente ricordi il risultato. Il modello tipicamente produce una montagna di osservazioni teoriche: manca la validazione della checklist OWASP qui, si potrebbe aggiungere un altro livello di sanitizzazione lì, e questa variabile ha un nome sospetto. In pratica, il 90% di questi risultati si rivela essere rumore che semplicemente spreca il tempo degli sviluppatori.

Il team di Cloudflare ha reso open source security-audit-skill. È un insieme di istruzioni e una pipeline per agenti di codifica, che hanno utilizzato per costruire il loro harness interno per il controllo continuo dei repository.

Qual è il Problema Principale con il Controllo AI Tradizionale

La maggior parte degli analizzatori statici e dei semplici prompt di reti neurali soffre di due problemi: non verificano la sfruttabilità e allucinano il contesto. La rete neurale vede una funzione pericolosa ma non nota che i dati in input sono già filtrati da tre livelli superiori.

Cloudflare ha adottato l'approccio opposto e ha costruito lo skill su principi rigorosi:

• I report vengono generati solo per ciò che è effettivamente sfruttabile. Frasi come "teoricamente un attaccante potrebbe" vengono immediatamente filtrate.
• La persona che ha trovato il bug non ha il diritto di validarlo. Un agente indipendente separato agisce nel ruolo di avvocato del diavolo per la verifica.
• L'assenza di un secondo livello di protezione non è considerata una vulnerabilità se il primo livello blocca affidabilmente il vettore di attacco.
• La valutazione della criticità si basa sull'impatto reale, non sulle corrispondenze formali con le checklist.

Come Funziona la Pipeline a Sei Fasi

invece di un lungo prompt, lo strumento suddivide il lavoro in sei fasi sequenziali. Sotto-agenti paralleli lavorano al loro interno, ciascuno con un compito rigorosamente definito.

0

1. Ricognizione

Gli agenti investigano il progetto, definiscono i confini di fiducia, identificano i punti di ingresso e mappano l'architettura complessiva. Il risultato è un file 5 che funge da mappa per gli agenti attaccanti.

2. Caccia

Agenti multipli testano il codebase in parallelo da angolazioni diverse. Il progetto viene suddiviso in file separati con prompt per diverse classi di attacco:

• Iniezioni, controllo degli accessi e logica di business.
• Specifiche dei protocolli web, caching e autenticazione (6).
• Minacce lato client come iniezioni DOM e inquinamento del prototipo (7).
• Sicurezza della memoria e vulnerabilità binarie per codice nativo (8).
• Problemi dei sistemi LLM: iniezione di prompt, fughe di contesto e manipolazione delle chiamate degli strumenti (9).

Ogni agente di caccia può generare processi aggiuntivi per approfondire le catene di chiamate sospette.

3. Validazione Avversariale

La fase più utile. Agenti freschi ricevono un elenco di potenziali bug e cercano deliberatamente di dimostrare che un attacco non funzionerà. Se la protezione è presente o il vettore è bloccato da un modulo vicino, il risultato viene spietatamente eliminato.

4. Report e Output Strutturato

Vengono generati i file 10 e 11 con tracce dettagliate per le vulnerabilità di livello Medio e superiore, insieme a 12. Il JSON strutturato viene validato dallo script 13 basato su Node.js senza dipendenze esterne.

5. Verifica Indipendente

Controllo qualità finale. Agenti con contesto pulito verificano riga per riga le affermazioni nel report contro il codice effettivo per eliminare le allucinazioni nei numeri di riga o nei nomi delle funzioni.

Installazione ed Esecuzione

Il pacchetto si connette tramite Skills CLI a qualsiasi agente di codifica che supporta le chiamate di strumenti e i sotto-agenti paralleli.

Installazione del progetto:

1

Installazione globale per l'intero sistema:

2

Dopodiché, basta aprire il codebase nel tuo agente e scrivere in testo normale:

3

oppure specificare una directory specifica e un percorso del report:

4

Dettaglio interessante: le esecuzioni possono essere accumulate. Gli autori hanno scoperto durante i test che una singola esecuzione trova circa la metà dei problemi reali a causa della casualità nei percorsi di attraversamento. Lo skill può leggere i 14 precedenti, saltare i bug già noti ed esplorare rami del codice non ancora analizzati.

A Chi Serve

Lo strumento richiede un modello capace con supporto per chiamate di strumenti parallele, quindi eseguirlo su configurazioni locali deboli probabilmente non funzionerà.

Ma se stai già usando agenti per il refactoring o per scrivere test, aggiungere un ruolo come revisore di sicurezza meticoloso è un'ottima idea prima di una release o di un merge importante. L'approccio di dividere i ruoli tra "attaccante" e "scettico" riduce notevolmente lo sforzo manuale necessario per gestire i falsi positivi.