security-audit is a skill that turns a coding agent such as Claude Code into a security auditor for a codebase. It isn't a scanner. It runs a structured audit with several isolated agents: one set hunts for vulnerabilities, a separate set tries to disprove every finding, and the result is a report plus a machine-readable findings file.
It's the seed of Cloudflare's own vulnerability discovery system, published as the open single-repo starting point that the internal harness grew from.
| Maker | Cloudflare |
| Licence | MIT |
| Language | Markdown instructions, plus 2 zero-dependency JavaScript validators |
| Created | 18th June 2026, with a rework of the workflow on 10th September |
| Traction | 19,454 stars, 1,095 forks |
| Needs | An agent with tool use and parallel sub-agents, plus Node.js |
What it does
An audit runs in 6 phases:
- Reconnaissance. Map the architecture, trust boundaries and input surfaces, and build a coverage ledger of what needs checking.
- Coverage-led hunting. Isolated hunter agents take units from the ledger. Coverage critics then look for the gaps.
- Candidate validation. Every candidate goes to a fresh verifier whose job is to disprove it.
- Structured output. Each result lands in
findings.jsonasconfirmed,needs_validationorrejected, validated against a JSON schema. - Independent record verification. More fresh agents re-check the final claims against the source.
- Reporting.
REPORT.md,FINDINGS-DETAIL.mdandNEEDS-VALIDATION.md, all derived from the verified records.
The 3 verdicts mean different things. Confirmed needs a complete source trace and an observed result. Needs validation is a specific, source-grounded lead blocked by one exact missing fact, and it carries no severity. Rejected is a candidate the verifier disproved.
Runs are additive. A second run reads the first run's ledger and findings, targets the gaps, and re-checks anything whose source changed. Cloudflare's own finding: a single run found roughly half of the vulnerabilities that repeated runs found in total.
For business people
The problem it solves is the one that makes AI security reviews hard to trust: agents produce confident-sounding findings, and a lot of them are wrong. This skill attacks that directly. The agent that finds a problem is never the agent that confirms it, and severity is only assigned to confirmed findings with a demonstrated impact.
- Useful for a first security pass on internal tools, side projects, and code written fast with AI, before it touches customer data.
- Cost: the skill is free. The spend is agent time, and a full audit launches many agents. A budget setting caps the total number of agent invocations, and the skill says so upfront if a budget can't fund a meaningful pass.
- Limits: it reads source code and runs local tests in a sandbox. It never probes live systems. Anything that depends on deployment settings it can't see comes back as "needs validation", not as a guess.
- Not a replacement for a professional penetration test on anything high-stakes. It's a disciplined, repeatable first pass.
The internal system behind it shows the scale. Cloudflare's launch post reports 20,799 raw candidates narrowing to 7,245 actionable findings after validation and deduplication, with the validation rejection rate falling from 40% to 11% as the system improved.
For technical people
Install and run
It installs with the Skills CLI, per project or globally:
npx skills add https://github.com/cloudflare/security-audit-skill \
--skill security-audit --global
Then ask the agent from inside the repository:
security audit this codebase
find security vulnerabilities in ./src
do a security review, output to ~/audits/my-project
A direct audit request runs full audit mode, all 6 phases. Security questions and focused reviews run guidance mode: it uses the relevant parts without creating files. Output defaults to ~/security-audit-skill/<repo-name>/run-<N>, outside the target, and never writes inside the repository unless you pick a directory that version control ignores.
Profiles and scope
| Profile | Use for | What changes |
|---|---|---|
quick |
Small targets, re-runs, a first look | 1 hunter wave, 1 critic pass, 1 verifier per candidate |
standard |
The default | The workflow as written |
deep |
Large or high-stakes targets | Finer ledger units, critic waves until clean, separate verifiers |
A scoped run covers named paths, 1 subsystem, or the diff between 2 commits, and marks everything else out of scope rather than covered. Profiles change breadth, never the evidence bar.
What makes it rigorous
- A boundary or nothing. Every candidate must name the lower-trust actor, the input, the control it defeats, the boundary crossed and the concrete result. A missing best practice isn't a finding.
- Severity anchors. Critical means unauthenticated code execution or full data access. High means an explicit control is fully defeated. If you can't state the concrete damage, it's lower than it feels.
- Deterministic checks.
validate-findings.cjsandvalidate-coverage-ledger.cjsenforce the schema and the coverage claim. The run can't finish until both pass or the gap is declared. - 10 domain playbooks, on top of a core attack-class file, for specific attack surfaces: AI and LLM prompt injection, web protocols and auth, client-side code, supply chain, cloud and deployment, RPC and messaging, data isolation, desktop and mobile, memory safety, and resource exhaustion.
- A strict execution sandbox. Running target code requires no network, an allowlisted environment, read-only source and resource limits. Without every control, it doesn't execute anything and keeps the lead as "needs validation".
⚠️ WARNING: the sandbox rule decides how deep an audit goes. Without an OS-enforced sandbox, the skill stays static: it traces source but never runs the code, so more findings end as "needs validation" instead of "confirmed".
Lessons from the full harness
The launch post is worth reading for 2 findings beyond the skill. The most-used feature was a "wishlist" that let agents request missing tools, with 25,472 uses. The static-analysis tool Semgrep, although integrated, got 0 invocations: the agents preferred reading and running code directly.
Value
The design is the lesson. Most AI code review stops at "the model found something". This skill treats every finding as a claim to disprove, separates certainty from severity, and makes coverage countable, so a second run knows what the first missed.
For my own work, it's the obvious first pass on the projects I build fast and never audit: the lab projects holding API keys in .env files, the static-site scripts, the shared tools. Start with a quick scoped run on one project, read NEEDS-VALIDATION.md as seriously as the confirmed list, and re-run after fixes, because a single pass finds about half of what's there.
Further Reading
