Cloudflare ha open-sourcato security-audit-skill, una coding-agent skill che orchestra agenti isolati attraverso un audit di sicurezza multi-fase con finding indipendentemente verificati e machine-readable. Non è uno scanner standalone, ma un insieme di istruzioni, checklist di attacco e validatori zero-dependency che trasformano un agent esistente (Claude Code, Codex o simili) in un auditor strutturato.
La skill è il punto di partenza single-repo da cui è evoluto l’harness interno di vulnerability discovery descritto nel post Build your own vulnerability harness. In circa sei settimane quel seme di ~450 righe è diventato un sistema fleet-wide che ha coperto 128 repository.
Le sei fasi dell’audit
Il workflow completo si attiva solo su richiesta esplicita di audit o pen-test del codebase (full audit mode). In guidance mode resta più leggero.
- Reconnaissance: mappa architettura, trust boundary, superfici di input e coverage deterministica in architecture.md e coverage-ledger.json.
- Coverage-led hunting: assegna hunter isolati alle unità del ledger e usa critic per trovare gap.
- Candidate validation: ogni candidato unico va a un verifier fresco che tenta di confutarlo.
- Structured output: scrive record confirmed, needs_validation e rejected in findings.json, validati contro report-schema.json.
- Independent record verification: agenti freschi ricontrollano le claim finali sulla sorgente.
- Target-neutral reporting: deriva REPORT.md, FINDINGS-DETAIL.md e NEEDS-VALIDATION.md dai record verificati.
I verdict sono distinti: confirmed richiede traccia sorgente completa e risultato osservato delimitato; needs_validation ha un fatto irrisolto esatto e nessuna severity; rejected registra un candidato disproved.
Principi di design e limiti
La skill conferma solo fallimenti di boundary stabiliti. La validazione è sempre avversariale: chi verifica non è chi ha trovato. La severity richiede impatto reale (likelihood × impact). I gap di defense-in-depth restano note di hardening, non vulnerabilità.
Un singolo run trova circa la metà dei bug emersi in run ripetuti. I run multipli sono additivi: usano ledger e finding precedenti per coprire gap e rivedere codice cambiato.
Per eseguire build, test o PoC del target serve un sandbox OS-enforced (no networking esterno, environment sanitizzato, limiti di risorse, write solo su scratch). Senza, i lead restano needs_validation.
Metriche dell’harness interno
Secondo il blog Cloudflare del 18 giugno 2026 (autori Dan Jones, Alexandra Godoi, Grant Bourzikas):
- 20.799 candidati grezzi dal Vulnerability Discovery Harness (VDH).
- Circa 12.057 sopravvissuti alla validazione.
- Pool combinato VVS di 13.841 finding su 145 repository.
- 5.442 duplicati e 1.154 item wrong-repo o low-risk rimossi.
- 7.245 finding azionabili inviati ai team di engineering.
Questi numeri riguardano il sistema interno, non la skill pubblica. La skill pubblica è il punto di partenza model-agnostic e single-repo.
Installazione e uso
Si installa con il Skills CLI:
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit
Aggiungere --global per installazione user-level. Poi, nell’agent puntato al repo, basta chiedere “security audit this codebase” o “find security vulnerabilities in ./src”.
Richiede un agent con tool use e sub-agent paralleli, più Node.js per i validatori. Output di default in ~/security-audit-skill/<repo>/run-N.
Fonti
Testo: assistito da AI · revisionato da Carlos H. P. Ross




