Cloudflare apre il suo auditor: la chiave è il contraddittorio

Cloudflare ha pubblicato questa settimana una skill che trasforma un agente di coding in un revisore di sicurezza, ed è diventata il repository in più rapida crescita nella classifica settimanale di GitHub: circa 16,400 stelle in sette giorni, 51.000 in totale. La presentazione dell’azienda è di una modestia inusuale: è il punto di partenza su singolo repository da cui si è evoluto il suo harness interno di scoperta delle vulnerabilità, rilasciato perché altri possano costruirne uno proprio.

Quello che vale la pena leggere non è il catalogo delle classi di attacco, per quanto sia ampio. È la parte su come i risultati vengono messi in discussione.

Sei fasi, una delle quali è pura contabilità

Il flusso di lavoro è strutturato, non conversazionale, ed è la prima cosa che lo distingue dal «chiedi a Claude di trovare bug».

La prima fase è la ricognizione: mappare l’architettura, i confini di fiducia, le superfici di input e, questo è il punto inusuale, scriverli in architecture.md e coverage-ledger.json. La seconda assegna cacciatori isolati alle unità di quel registro, annota cosa ha controllato ciascuno, poi esegue critici di copertura per trovare ciò che nessuno ha guardato. La terza affida ogni singolo candidato a un verificatore nuovo, il cui compito è confutarlo. La quarta scrive record confirmed, needs_validation o rejected in findings.json e li valida contro uno schema JSON. La quinta fa verificare le affermazioni finali sul codice a agenti nuovi, e ogni sostituzione sostanziale passa da un altro verificatore indipendente. La sesta deriva i report dai record verificati.

I due validatori sono semplici script Node senza dipendenze: validate-coverage-ledger.cjs gira dopo la creazione del registro e dopo ogni aggiornamento, validate-findings.cjs nella fase quattro e di nuovo dopo ogni sostituzione della fase cinque. Sono i file meno interessanti del repository e la ragione per cui il resto sta in piedi. Un agente che non riesce a produrre un risultato conforme allo schema non può sostenere di averne trovato uno.

I tre verdetti sono il vero design

Quasi tutti gli strumenti di sicurezza per agenti hanno due uscite: un elenco di bug o niente. Questo ne ha tre, e la categoria intermedia è dove sta il ragionamento.

confirmed significa una traccia completa nel codice sorgente più un risultato delimitato e osservato. needs_validation significa un fatto irrisolto ed esatto, senza gravità assegnata. rejected significa un candidato attivamente confutato, registrato invece che cancellato.

Il terzo è insolito e, credo, corretto. Un candidato confutato è una prova sul codice: dice all’esecuzione successiva di non perderci tempo e dice al revisore cosa è stato considerato. Quasi tutti gli strumenti buttano via questa informazione.

Il principio di progettazione sottostante è enunciato senza giri di parole nel README: confermare solo i fallimenti di confine già stabiliti e, se una pista fondata sul codice si blocca, lasciarla in needs_validation con il suo fatto esatto irrisolto invece di promuoverla a risultato. C’è una regola collegata: le lacune di difesa in profondità non sono vulnerabilità. Se lo strato A blocca l’attacco, l’assenza dello strato B è una nota di hardening.

Chiunque abbia letto un report di vulnerabilità generato da una macchina sa esattamente perché esistono queste regole. La modalità di fallimento della revisione di sicurezza affidata a un LLM non è perdere bug. È rumore sicuro di sé: pattern che sembrano vulnerabilità, segnalati con gravità alta, che bruciano una settimana a un team di triage.

Validazione adversariale, alla lettera

La frase più importante: l’agente che controlla un risultato non è mai l’agente che lo ha trovato.

Non è un’istruzione nel prompt, è un vincolo di orchestrazione, ed è l’unico modo in cui questo tipo di strumento produce qualcosa di affidabile. Un LLM a cui si chiede se il proprio risultato è corretto sarà d’accordo con se stesso. Dagli un contesto nuovo, un’altra istanza di agente e il compito esplicito di confutare l’affermazione, e ottieni qualcosa di più vicino a una code review.

La fase cinque estende il principio: agenti nuovi verificano le affermazioni finali sul codice e, se un’affermazione viene sostituita in modo sostanziale, un altro verificatore indipendente controlla la sostituzione. Tra il cacciatore e il record che sopravvive ci sono due livelli di separazione.

Il numero onesto

Sepolto nei principi di progettazione c’è questo: nei test di Cloudflare, una singola esecuzione trovava circa la metà delle vulnerabilità che esecuzioni ripetute trovavano in totale.

Pubblicarlo è una scelta. Ti dice che lo strumento è una macchina di copertura, non un oracolo, e ricolloca il flusso di lavoro: non lo si esegue una volta prima di una release, lo si esegue ripetutamente e si lasciano accumulare i registri. Il repository lo sostiene esplicitamente: più esecuzioni sullo stesso repository sono additive, usano registri e risultati precedenti per puntare ai vuoti, rivalidano il codice modificato e portano avanti le prove del codice attuale senza trattare il lavoro obsoleto come coperto.

La metà è anche una stima ragionevole per revisori umani al primo passaggio, il che è rassicurante o devastante a seconda di come si guarda alla professione.

Il requisito che fermerà quasi tutti

Il README elenca un requisito rigido che quasi tutti gli utenti salteranno e poi incontreranno: una sandbox imposta dal sistema operativo per build, test, processi, browser, emulatori, fuzzer e fixture, con rete esterna disabilitata, ambiente ripulito e in allowlist, limiti di risorse applicati e scritture limitate a percorsi temporanei.

Senza questi controlli, il flusso di lavoro tiene la pista in needs_validation invece di eseguire il codice di destinazione. È la decisione giusta — dopotutto stai facendo girare i suggerimenti di un modello linguistico contro una base di codice — ma significa che lo strumento degrada a esercizio di analisi statica e ragionamento per chi non ha infrastruttura a container.

Significa anche che non è uno strumento da portatile, nonostante la riga di installazione con npx. L’installazione è un solo comando:

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit

E l’uso consiste semplicemente nel chiederlo:

security audit this codebase

Il contrasto è strano: l’invocazione è una frase, i prerequisiti sono una politica di sandbox. In quello scarto finirà la maggior parte dello sforzo di adozione.

Com’è davvero l’output

Tre artefatti, derivati e non scritti: REPORT.md, FINDINGS-DETAIL.md e NEEDS-VALIDATION.md, più il findings.json sottostante e il registro di copertura.

Questa separazione è più utile di quanto suoni. Un unico report di vulnerabilità costringe ogni risultato nello stesso registro, ed è così che ti ritrovi una SQL injection critica accanto a un header CSP mancante. Separare i risultati confermati, le domande aperte e le sintesi derivate significa che chi legge NEEDS-VALIDATION.md sa di guardare lavoro in corso, non risultati.

La directory di output predefinita è ~/security-audit-skill/<repo-name>/run-<N>, e il flusso di lavoro scrive dentro il repository di destinazione solo se lo indirizzi esplicitamente a una directory ignorata da git. Dettaglio piccolo, istinto giusto: gli artefatti di audit in un repository finiscono committati per errore, e un elenco committato di vulnerabilità non corrette è di per sé un incidente.

Come capire se ha funzionato

Eseguilo due volte. È il test che il README suggerisce senza dichiararlo: poiché le esecuzioni sono additive e una sola trova circa la metà, la seconda esecuzione sullo stesso commit è una misura diretta della copertura dello strumento sul tuo codice. Se la seconda non fa emergere nulla di nuovo, o sei pulito o le classi di caccia non corrispondono al tuo stack.

Poi guarda il log dei rifiuti. Un’esecuzione che conferma cinque problemi e ne respinge quaranta candidati sta facendo il suo lavoro. Una che ne conferma quaranta e non ne respinge nessuno ha smesso di verificare, e quei quaranta andrebbero letti a mano prima di crederne uno.

Cosa dice della categoria

Tre cose, brevemente.

Le skill per agenti stanno diventando una forma di distribuzione. Non è una libreria da importare, è una cartella di markdown e due script di validazione che un modello legge a runtime. Il repository è una ventina di file di istruzioni più cataloghi di classi di attacco divisi per tipo di bersaglio: sicurezza della memoria e binari, superfici LLM e agenti, protocolli web e autenticazione, lato client, supply chain, cloud e deployment, RPC e messaggistica, esaurimento delle risorse, isolamento dei dati, desktop e IPC locale. Quella struttura è il prodotto.

La verifica sta diventando il fattore distintivo. Oggi ogni fornitore sa generare un risultato plausibile. Quasi nessuno sa dirti quali hanno superato un passaggio adversariale, scritti contro uno schema, con i confutati conservati.

E l’abitudine del numero onesto si sta diffondendo. Un fornitore che pubblica «ne abbiamo trovati la metà» è un fornitore la cui prossima affermazione è più credibile.

Il repository è sotto licenza MIT, il che significa che la domanda interessante non è se funziona, ma se il tuo team può permettersi la sandbox che gli serve per funzionare davvero.