security-audit-skill di Cloudflare: trasformare un agente AI in auditor di sicurezza

security-audit-skill è un repository pubblicato da Cloudflare, con licenza MIT, che contiene una skill per coding agent: una volta installata trasforma l'agente in un auditor di sicurezza del codice. Secondo la pagina del progetto, è il «punto di partenza a singolo repository» da cui è nato l'harness di vulnerability discovery usato internamente da Cloudflare, poi evoluto in un sistema a più stadi.

Che cosa fa

Invece di chiedere a un modello «cerca le vulnerabilità» in un colpo solo, la skill orchestra più agenti isolati lungo un processo in sei fasi:

1. Reconnaissance — mappa architettura, confini di fiducia (trust boundary), superfici di input e prove precedenti, scrivendo architecture.md e un registro di copertura, coverage-ledger.json;
2. Coverage-led hunting — assegna «cacciatori» isolati alle unità del registro, annota i controlli eseguiti e usa dei coverage critic per scovare le parti rimaste scoperte;
3. Candidate validation — ogni candidato passa a un verificatore nuovo che prova a smentirlo;
4. Structured output — i risultati finiscono in findings.json, validato con report-schema.json;
5. Independent record verification — altri agenti, senza contesto pregresso, ricontrollano sul sorgente le affermazioni di ogni record;
6. Target-neutral reporting — dai record verificati vengono generati REPORT.md, FINDINGS-DETAIL.md e NEEDS-VALIDATION.md.

Tre verdetti, non due

La scelta di progetto più interessante è che un candidato non è semplicemente «vulnerabile» o «falso positivo». I verdetti sono tre:

• confirmed — c'è una traccia completa dal sorgente e un risultato osservato e circoscritto;
• needs_validation — il fatto esatto non è risolto: resta in una lista a parte e senza severità;
• rejected — il candidato è stato smentito.

I principi dichiarati vanno nella stessa direzione: confermare solo cause stabilite di rottura di un confine, assegnare la severità solo in presenza di un impatto (probabilità × impatto) e non trattare come vulnerabilità la semplice assenza di un secondo livello di difesa quando il primo già blocca l'attacco: quella è una nota di hardening. Chi verifica non è mai chi ha trovato il problema.

Che cosa cerca

Le classi di attacco sono distribuite in file Markdown tematici, così l'agente carica solo quelle pertinenti al bersaglio. Tra gli altri, il repository include classi per:

• memory safety, binari e kernel;
• sistemi basati su LLM: prompt injection, agenti e strumenti, gestione dell'output;
• protocolli web e autenticazione (framing HTTP, cache);
• lato client: DOM injection, fiducia nei messaggi, prototype pollution;
• supply chain e release: dipendenze, CI, firma, aggiornamenti, plugin;
• cloud e deployment: IAM, infrastructure as code, container, serverless;
• RPC, serializzazione, code e webhook;
• esaurimento delle risorse e disponibilità;
• isolamento dei dati tra tenant e ciclo di vita (export, backup, cancellazione, restore);
• app desktop e mobile, deep link, webview e IPC locale.

Come si installa e si usa

L'installazione passa dalla Skills CLI:

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

Con --global si installa a livello utente invece che nel progetto. Poi basta chiedere all'agente, per esempio:

security audit this codebase
find security vulnerabilities in ./src
do a security review, output to ~/audits/my-project

Una richiesta di audit diretta attiva la full audit mode; una domanda di sicurezza o un lavoro mirato usa la guidance mode, senza produrre i report, a meno che non vengano chiesti. Se non si indica una cartella di output, i risultati vanno in ~/security-audit-skill/<repo>/run-<N>; la skill scrive dentro il repository esaminato solo se si sceglie esplicitamente una cartella ignorata dal controllo di versione.

Le esecuzioni ripetute sullo stesso repository sono additive: usano registro e risultati precedenti per puntare alle lacune e rivalidare il codice cambiato. Gli autori dichiarano che una sola esecuzione ha trovato circa la metà delle vulnerabilità trovate da più esecuzioni insieme: conviene quindi pensarla come un processo da ripetere, non come un controllo una tantum.

Requisiti e cautele

• Un agente con sub-agent paralleli: serve un coding agent con un modello che supporti l'uso di strumenti e l'esecuzione di sotto-agenti in parallelo; Node.js serve per i validatori JSON inclusi.
• Una sandbox del sistema operativo: per eseguire build, test, browser o fuzzer sul codice esaminato la pagina richiede un ambiente isolato, senza rete esterna, con variabili d'ambiente ripulite, limiti di risorse e scritture solo nelle cartelle di lavoro. Senza questi controlli la skill non esegue il codice del bersaglio e il sospetto resta needs_validation.
• Costo: più agenti, più passaggi e più esecuzioni significano un consumo di token sensibilmente superiore a una normale revisione del codice. Il repository non riporta stime di costo.
• Non sostituisce un penetration test: è un'analisi del sorgente assistita da modelli; i risultati vanno comunque letti da una persona competente.

Perché ci riguarda

Per chi sviluppa software gestionale la novità non è tanto l'elenco di classi di attacco, che è familiare, quanto il metodo: registro di copertura per sapere cosa è stato davvero guardato, verifica indipendente di ogni segnalazione e una categoria esplicita per ciò che non si riesce a provare. È lo stesso approccio che rende utile una code review umana ben fatta, applicato in modo sistematico. Se usi già Claude Code o un agente analogo, può valere un tentativo su un progetto non critico, in sandbox, per valutare il rapporto fra segnalazioni utili e rumore prima di estenderlo agli altri.

Per approfondire: OpenCodeReview per la revisione del codice con l'AI, i rischi del software aziendale fatto in casa con l'AI e i rischi degli agenti AI autonomi.