Security audits are one of those things small teams either can't afford or quietly push down the priority list. The procurement requirement says "annual penetration test required." The quote from a competent consultancy says $40,000–$80,000. You tell yourself you'll handle it when a client actually asks for evidence.
Cloudflare just changed that math. On September 14, they pushed the latest version of security-audit-skill — the open-source AI coding agent skill that seeds their own internal vulnerability discovery harness — and it went from a niche GitHub project to trending #1 on the platform.
One CLI command. Runs inside your existing AI coding agent. Produces structured, independently-verified findings with full evidence chains.
Here's what it actually does.
Six phases, not a vibe check
"Ask your AI coding agent if your code is secure" produces confident-sounding non-answers. This is different. The skill runs a structured six-phase workflow across isolated agents:
Phase 1: Reconnaissance. The agent maps your architecture, identifies trust boundaries, catalogs input surfaces, and documents everything to architecture.md and coverage-ledger.json. No hunting starts until the landscape is on paper.
Phase 2: Coverage-led hunting. Isolated hunter agents pick up units from the coverage ledger and look for vulnerabilities. The ledger ensures every component gets examined — not just the obvious entry points.
Phase 3: Candidate validation. For every finding, a fresh validation agent — one that hasn't seen the original hunt — tries to disprove it. This is what kills false positives. If a validator can't independently reproduce the vulnerability, it gets rejected.
Phase 4: Structured output. Findings land in findings.json in three states: confirmed (full source trace), needs_validation (unresolved question the agent couldn't close), or rejected (disproved). Machine-readable, not a wall of prose.
Phase 5: Independent record verification. Another fresh agent verifies the source claims in confirmed findings. Every citation gets checked.
Phase 6: Target-neutral reporting. Three documents: REPORT.md (executive summary), FINDINGS-DETAIL.md (full evidence chains), and NEEDS-VALIDATION.md (items that need human judgment or a deeper dig).
Scope covers memory safety, prompt injection, HTTP/authentication protocols, client-side attacks, supply chain issues, cloud misconfigurations, resource exhaustion, and data isolation. Architecture-agnostic — it reads whatever codebase you point it at.
Why the September update matters
The September 10-14 commits weren't cosmetic tweaks. Cloudflare described the September 10 push as a full rework of the audit workflow, findings contract, and validators. The previous version was a starting point; this version is what they actually run internally.
That distinction is worth sitting with. This isn't an academic project or a marketing piece they shipped for developer goodwill. It's the tooling Cloudflare's security research team uses to find real vulnerabilities at scale. They decided to open-source it under MIT. The blog post walking through how they built a full vulnerability harness on top of it — "Build your own vulnerability harness" — is linked directly from the repo.
The practical case for a 15-person team
A traditional penetration test from a competent consultancy starts at $15K. Comprehensive coverage is more like $40K–$80K. You get a PDF in three weeks. The findings reflect your codebase on the day the consultant ran their tools. Six months later, your code has changed and the report is already dated.
This runs in your workflow. Every time you ship a feature touching authentication, payments, or user data, you can run an audit on the diff. You're not waiting for an annual engagement to find out you introduced a server-side request forgery on the last sprint.
For a small dev team, the concrete uses are: run this before you ship anything that handles money or health data. Run it before you hand off a build to a client. Run it after a contractor's code lands in your repo and you want to verify it before it goes to production. Run it when you're applying for a security certification and need documented evidence of your process.
The output is also actually useful for people who didn't write the vulnerable code. The confirmed findings include full evidence chains with file locations and line numbers. A developer who inherited a codebase can understand exactly what's wrong and where — no context required.
What it doesn't replace
Business logic flaws that require understanding your specific domain: an insurance platform where claims can be submitted in a sequence that bypasses fraud detection — that's outside this tool's scope. So is anything that requires an attacker to have external knowledge about your deployment that isn't visible in the code.
For those, you still want human review. But that's now a bounded conversation: "We ran the automated audit, here are the confirmed findings we've already patched, here are the needs-validation items we want your eyes on." That's a very different engagement from "can you audit our whole codebase from scratch." Shorter, cheaper, more focused.
Setting it up
npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit
Then tell your AI coding agent to "security audit this codebase." The README covers configuration for full audit mode versus a faster targeted sweep — useful when you're running this on a large codebase and don't want to burn tokens on every component every time.
Requirement: your coding agent needs to support tool use and parallel sub-agents. Most of the current generation does. If you're running Claude Code, Cursor, or similar, you're covered.
One thing to have ready: the output is dense. The first time you run this on a mature codebase, you may get a long list of needs_validation items alongside the confirmed findings. Work through the confirmed items first — those have full evidence chains and are the highest-confidence fixes. The needs-validation list is where you'll want someone to make a judgment call.
The window
The consulting firms haven't repriced yet. The clients asking "do you have a security audit?" haven't heard about this yet. Right now, running this before your competitors do is a straightforward differentiator — and for organizations that handle sensitive data, it's a risk management move that costs one afternoon.
That shift from "we can't afford an audit" to "we audit every release" is the kind of operational change we help small teams actually implement, not just understand. If you want help wiring this into your workflow or making sense of what the findings actually mean, we're easy to reach.