Cloudflare’s Security Audit Skill: AI Code Audits With Verified Findings

1. What the Security Audit Skill Is

The GitHub description is precise: “A coding-agent skill for multi-phase security audits with independently verified, machine-readable findings.” The README adds that it “orchestrates isolated agents through reconnaissance, coverage-led hunting, candidate validation, structured output, independent record verification, and target-neutral reporting.” In plain words: your agent becomes the coordinator (the skill calls it the parent), and each unit of work goes to a fresh sub-agent with its own instructions and no knowledge of what the others concluded.

What you install is Markdown plus two Node scripts: no binary, no service, no API key of its own. Your agent’s model does the reading and reasoning; the skill supplies the method — who does what, what counts as a finding, what evidence it needs and how to prove it. That’s also why results depend on the agent and model you run it with, and why the same repo can produce different results on different runs.

2. The Architecture in 4 Steps

The README lists six phases. I group them into four steps, because phases 3 and 5 are both independent verification and phases 4 and 6 are both output:

3. Quickstart With Claude Code

The README lists three requirements. The third is the one people skip:

Install it with the Skills CLI. These are the README’s own commands — project-level first, then user-level with --global:

# Project-level install (README)
npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit

# User-level install, available in every repo (README)
npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit \
  --global

To skip the agent picker and target Claude Code directly, the Skills CLI documents -a (agent) and -y (skip confirmation prompts). Its agents table puts Claude Code skills in .claude/skills/ for a project and in ~/.claude/skills/ globally:

# Target Claude Code only and skip the prompts (-a and -y from the Skills CLI docs)
npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit -a claude-code -y

# Project: .claude/skills/security-audit/
# Global (--global): ~/.claude/skills/security-audit/

Then start Claude Code inside (or pointed at) the repo you want to audit and ask. These three prompts come straight from the README; the skill activates on requests like “security audit”, “find vulnerabilities” or “pen-test the code”, and you can also call it explicitly with /security-audit:

security audit this codebase

find security vulnerabilities in ./src

do a security review, output to ~/audits/my-project

Two behaviors worth knowing before you hit enter. First, a direct audit or pen-test request runs full audit mode, while a security question or a focused review runs guidance mode, which writes no audit files; if the request is ambiguous, SKILL.md tells the agent to ask you one question first. Second, output defaults to ~/security-audit-skill/<repo-name>/run-<N>, outside your repo. It writes inside the target only if you explicitly pick a directory that version control ignores.

SKILL.md also defines three run profiles — quick (one hunter wave, one final critic, one verifier per candidate), standard (the default) and deep (finer units, critic waves until a clean pass, separate verifiers) — plus scoped runs on named paths, one subsystem or the diff between two refs, and an optional budget measured in agent invocations. The profile is picked from your request, so I simply state it (my phrasing):

security audit this codebase, quick profile, scoped to src/api, budget 20 agents

When the run finishes, re-run the validators yourself. These are the invocations from VALIDATION-AND-REPORTING.md, with the paths that a project-level Claude Code install and the default output directory produce:

node .claude/skills/security-audit/validate-findings.cjs \
  ~/security-audit-skill/my-api/run-1/findings.json

node .claude/skills/security-audit/validate-coverage-ledger.cjs \
  ~/security-audit-skill/my-api/run-1/coverage-ledger.json

4. What the Output Looks Like

A full-audit run directory, assembled from the files that SKILL.md and the phase guides define (the comments are my summary):

~/security-audit-skill/my-api/run-1/
├── run-metadata.json      # run_id, repo, source_ref, profile, scope_paths, budget, run_status
├── architecture.md        # phase 1 map: stack, principals, trust boundaries, entry surfaces
├── coverage-ledger.json   # units: planned → in_progress → covered | candidate | blocked | deferred
├── findings.json          # confirmed + needs_validation + rejected records
├── REPORT.md              # profile, scope, posture, findings table, coverage summary
├── FINDINGS-DETAIL.md     # full trace + local reproduction for medium/high/critical
├── NEEDS-VALIDATION.md    # leads with exact blockers and resolution plans, no severity
└── agents/<agent-id>/
    ├── scratch/           # the only place a sub-agent (and target code) may write
    └── artifacts/         # parent-owned, filled only by the safe promotion procedure

findings.json is an array of records, each with a verdict. The schema uses additionalProperties: false, so each verdict has a strict field contract:

Here is the shape of a confirmed record. The field names come from report-schema.json; the values are an invented example of mine, trimmed with “…”:

[
  {
    "verdict": "confirmed",
    "fingerprint": "api/invoices:cross-tenant-read",
    "title": "Invoice lookup skips the tenant check",
    "description": "…",
    "root_cause": "findInvoiceById filters by id only, not by tenant_id",
    "intended_behavior": "Users can read only invoices of their own tenant",
    "trace": [
      { "kind": "entrypoint", "file": "src/routes/invoices.ts", "line": 42,
        "scope": "GET /invoices/:id", "description": "…" },
      { "kind": "sink", "file": "src/db/invoices.ts", "line": 17,
        "scope": "findInvoiceById", "description": "…" }
    ],
    "evidence": [{ "file": "src/db/invoices.ts", "line": 17, "description": "…" }],
    "conditions": [{ "kind": "authentication_level", "description": "Any logged-in user" }],
    "execution": {
      "attacker_perspective": "Dummy user of tenant A",
      "payloads": ["GET /invoices/1002"],
      "instructions": ["Run the dummy-tenant integration test inside the sandbox", "…"],
      "observed_result": "The tenant B dummy invoice is returned with HTTP 200"
    },
    "remediation": { "strategy": "Scope the query by the session tenant_id", "code_changes": [] },
    "severity": {
      "likelihood": { "score": "high", "reason": "…" },
      "impact": { "score": "high", "reason": "Cross-tenant read" },
      "overall_severity": "high"
    },
    "confidence": { "score": "high", "reason": "…" }
  }
]

Because it’s plain JSON, triage is a one-liner. My jq to list confirmed findings with their severity:

jq -r '.[] | select(.verdict=="confirmed") | "\(.severity.overall_severity)\t\(.title)"' \
  ~/security-audit-skill/my-api/run-1/findings.json

5. Cost, Usage Limits and Sandboxing

The skill is free; running it isn’t. There’s no official per-run price, but the files tell you how spend scales:

Then the sandbox. SKILL.md’s “Universal execution safety” rules apply in both modes: source inspection is read-only, and any target-controlled build, test, process, browser, emulator, fuzzer or fixture runs only inside an OS-enforced sandbox with all of these controls:

How does Claude Code’s own sandbox compare? Per its docs, /sandbox uses Seatbelt on macOS and bubblewrap on Linux and WSL2, limits writes to the working directory (plus a temp directory and any you add) and routes network traffic through a proxy whose allowlist starts empty. But the docs don’t mention CPU, memory or process limits, environment variables are inherited unless you deny them (sandbox.credentials.envVars or CLAUDE_CODE_SUBPROCESS_ENV_SCRUB), and if the sandbox can’t start, commands run unsandboxed unless sandbox.failIfUnavailable is true. My reading: a useful layer, not the full set of controls the skill asks for.

6. A Sensible Weekly or CI Routine

The repo documents no CI integration, no GitHub Action and no per-PR mode, and Cloudflare’s post is explicit that “The Fixer never merges code on its own; a human must review the branch.” What follows is my suggestion, not something the project ships:

Headless, this is roughly how I’d run it with Claude Code. It’s an untested sketch: every flag comes from Claude Code’s headless docs, but tune the permissions to your setup — Bash(node *) is broad and only acceptable on a throwaway machine:

# Weekly sketch (mine, untested end to end): run it on a disposable VM, not your laptop
mkdir -p ~/security-audit-skill
cd ~/src/my-api && git pull --ff-only

claude -p "/security-audit Full security audit of this codebase, quick profile, scoped to src/api" \
  --add-dir ~/security-audit-skill \
  --permission-mode acceptEdits \
  --allowedTools "Bash(node *)" \
  --max-budget-usd 30 \
  --output-format json > ~/security-audit-skill/last-run.json

RUN=$(ls -d ~/security-audit-skill/my-api/run-* | sort -V | tail -1)
node .claude/skills/security-audit/validate-findings.cjs "$RUN/findings.json"
node .claude/skills/security-audit/validate-coverage-ledger.cjs "$RUN/coverage-ledger.json"
jq -r '.[] | select(.verdict=="confirmed") | "\(.severity.overall_severity)\t\(.title)"' "$RUN/findings.json"

7. Where It Shines: Use Cases

Where I think it earns its usage bill:

The pattern: code you own, boundaries that matter, and a human who will read the evidence. That’s the profile the skill’s rules were written for.

8. When NOT to Use It

It’s a strong method, not a magic button. Honest boundaries:

Conclusion

The security-audit skill is the most interesting kind of trending repo: not a new tool but a written-down method — isolated hunters, adversarial verifiers, a coverage ledger and a strict schema — that any capable coding agent can follow. About 48K stars in just over four months, 15K of them in a single week, says many teams want exactly that discipline around AI-driven code review.

My suggestion: install it at project level, start with a quick, scoped run on one service you know well, check the confirmed records by hand, and see whether the needs_validation list matches the questions you’d ask yourself. If it earns its keep, move it to a disposable runner on a weekly schedule. And before you install any third-party skill — this one included — read it or scan it first.