Security Audit Skill

Security Audit Skill is a coding-agent skill from Cloudflare that drives an AI agent through a six-phase security audit of a repository and forces it to verify its own findings before it reports them. It is written for developers and security engineers who already run a coding agent on their codebase and want its security work to end in records they can check, rather than a page of confident prose that mixes real bugs with invented ones. The project is MIT-licensed, mostly JavaScript, and has gathered roughly 9,300 stars since it was published.

What it does

The skill replaces the usual "audit this repo for vulnerabilities" prompt with a fixed pipeline of six phases:

1. Reconnaissance — map the architecture, trust boundaries, input surfaces and prior evidence, and write them into architecture.md and a deterministic coverage-ledger.json.
2. Coverage-led hunting — assign isolated hunter agents to units from the ledger, record what each one checked, and run coverage critics to find the gaps.
3. Candidate validation — hand every unique candidate to a fresh verifier whose job is to disprove it.
4. Structured output — write confirmed, needs_validation and rejected records into findings.json and validate them against report-schema.json.
5. Independent record verification — send fresh agents to check the final source claims; any material replacement gets yet another independent verifier.
6. Target-neutral reporting — derive REPORT.md, FINDINGS-DETAIL.md and NEEDS-VALIDATION.md from the verified records and the coverage ledger.

The three verdicts are kept deliberately separate. A confirmed record carries a complete source trace and a bounded observed result. A needs_validation record names the exact fact that is still unresolved and carries no severity at all. A rejected record preserves a candidate that was disproved, so the next run does not chase it again. There is no vague "possible issue" bucket.

How it works

The design principle is that the agent that finds something is never the agent that confirms it. Hunters work in isolation from ledger units, so their coverage is traceable instead of a product of whatever the model happened to look at first. Validation is adversarial: a fresh verifier receives the candidate and tries to knock it down. Phase 5 then re-checks the surviving source claims with agents that did not produce them, and if a record is materially replaced, the replacement goes through another independent verifier rather than inheriting the earlier one's approval.

Around this sits deterministic plumbing rather than trust. The parent process runs validate-coverage-ledger.cjs after the ledger is created and after every later update to it, and runs validate-findings.cjs in phase 4 and again after each phase 5 replacement. Because the ledger and the findings are machine-readable files on disk, repeated runs against the same repository are additive: the skill reads the prior ledger and prior findings instead of starting from zero, so coverage accumulates over time.

The final reports are described as target-neutral — they are derived from the verified records and the ledger, not rewritten freehand by the agent at the end.

Getting started

The repository is the single-repo starting point for Cloudflare's own vulnerability discovery harness, described in the company's post "Build your own vulnerability harness"; the internal harness grew from here into a multi-stage, fleet-wide system, while this skill stays small enough to drop into one project. What ships is the skill definition, the two Node validator scripts and the JSON report schema, so the practical setup is to install it where your coding agent looks for skills and point it at a repository. Everything it produces — the architecture notes, the ledger, findings.json and the three Markdown reports — lands as ordinary files, which means you can commit them, diff them between runs and review them like any other artifact.

When to use it / when not

This is a good fit when you are auditing a codebase you control, you plan to audit it more than once, and you need to show someone else why a finding is real. The structured verdicts are also useful when an agent's output feeds a queue or a tracker, because confirmed and needs_validation mean different things to whoever picks the item up.

It is not a substitute for human security review. A needs_validation record is an honest statement that a fact is still open, and someone has to close it. Running many isolated agents through six phases also costs considerably more time and tokens than a single prompt, so it is aimed at a deliberate audit pass rather than something you run on every commit. And it is a starting point by design — the fleet-wide system Cloudflare built on top of it is not what you are downloading here.

Anyone who has asked a coding agent to review code for vulnerabilities and then spent an afternoon separating the two real issues from the eight imaginary ones should take this repository seriously. Its contribution is not a new detection technique but a process: isolate the hunters, make a different agent try to disprove each claim, validate the output against a schema, and keep a ledger of what was actually examined. That discipline is worth reading even if you end up adapting the phases to your own tooling.