Cloudflare's security-audit skill runs coding agents through a six-phase audit
cloudflare/security-audit-skill is an MIT-licensed coding-agent skill that splits a security audit across isolated agents, with independent verifiers and schema-checked findings.
What the skill is
cloudflare/security-audit-skill is a coding-agent skill that, in the README’s words, turns your agent into a security auditor. It orchestrates isolated agents through reconnaissance, coverage-led hunting, candidate validation, structured output, independent record verification and target-neutral reporting. The README says this skill seeded Cloudflare’s vulnerability discovery harness, which later grew into a multi-stage, fleet-wide system; the repository is the single-repo starting point it evolved from.
The project is MIT licensed and written mainly in JavaScript. It was created on 2026-06-18 and last pushed on 2026-09-14. In the GitHub trending snapshot it had 63664 stars, 2524 of them gained in the last day, and 4128 forks.
The six phases
Reconnaissance maps architecture, trust boundaries, input surfaces, prior evidence and deterministic coverage into architecture.md and coverage-ledger.json. Coverage-led hunting then assigns isolated hunters from units in that ledger, records their checks, and uses coverage critics to find gaps. In candidate validation, every unique candidate goes to a fresh verifier that tries to disprove it.
Structured output writes records to findings.json and validates them against report-schema.json. There are three verdicts: confirmed has a complete source trace and a bounded observed result, needs_validation carries an exact unresolved fact and no severity, and rejected records a disproved candidate. Independent record verification sends the final source claims to fresh agents, and a material replacement receives another independent verifier. The last phase derives REPORT.md, FINDINGS-DETAIL.md and NEEDS-VALIDATION.md from the verified records and the coverage ledger.
Two zero-dependency validators enforce the formats. The parent agent runs validate-coverage-ledger.cjs after creating the ledger and after each later ledger update, and validate-findings.cjs in Phase 4 and again after every Phase 5 replacement. Runs against the same repository are additive: prior ledgers and findings point later runs at gaps and changed source. The README says that in its authors’ test runs, a single run found roughly half of the vulnerabilities that repeated runs found in total.
Hunting prompts are split by target type, with separate files for memory safety and binaries, prompt injection and agent/tool handling in LLM-backed targets, web protocols and authentication, client-side code, supply chain and release, cloud and deployment, RPC and messaging, resource exhaustion, data isolation, and desktop, mobile and local IPC.
Installing and running it
The README installs it with the Skills CLI:
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-audit
Adding --global makes it a user-level installation. After that, the agent is started in the codebase and asked for an audit in plain language, for example:
security audit this codebase
A direct codebase audit or pen-test request uses full audit mode; security questions and focused vulnerability work use guidance mode unless report artifacts are requested. In full audit mode, output goes to ~/security-audit-skill/<repo-name>/run-<N> unless another directory is given, and the workflow writes inside the target repository only when the chosen directory is ignored by version control.
The sandbox requirement
The README asks for a model with tool use and parallel sub-agents, Node.js for the validators, and an OS-enforced sandbox for anything target-controlled: builds, tests, processes, browsers, emulators, fuzzers and fixtures. That sandbox must disable external networking, use a sanitized allowlisted environment, enforce resource limits and allow writes only to assigned scratch paths. Without these controls the workflow does not execute target code and keeps the lead as needs_validation instead.
The design principles follow the same line. The agent that checks a finding is never the agent that found it, severity requires impact, and a missing defense-in-depth layer is a hardening note rather than a vulnerability when another layer already prevents the attack.