Code Security Audit (Cloudflare security-audit)

Have an Agent run a structured security audit of a codebase: first map the architecture and trust boundaries, then hunt for vulnerabilities in parallel, hand every suspicion to another Agent to try to refute, and finally output a report backed by source-code evidence. It is built on Cloudflare's open-source security-audit-skill (MIT license). It is the starting point of Cloudflare's internal vulnerability discovery system; for the principles, see their article Build your own vulnerability harness.

This is a defensive audit: read the source, find problems that truly cross trust boundaries, and give evidence, a safe reproduction method, priority, and the minimal fix.

Triggers

Use it when a user wants a security audit of a codebase, vulnerability hunting, penetration-style review, or asks about the security of a specific piece of code. For small questions that do not need a full audit ("Is there SQL injection in this code?"), it only performs targeted analysis and does not start the full process.

Hard Rules

1. Audit only your own code or code you are authorized to audit. The audit target must be the user's own project, or a project the user is clearly entitled to review. If ownership is unclear, ask first.
2. Read source only, do not touch production. Do not probe deployed services, external interfaces, shared infrastructure, or other people's data, do not run availability tests against live environments, and do not spend paid API quota. When the decisive facts lie outside the code, mark them as "pending validation" instead of testing live.
3. Do not run target code without a sandbox. When building, running tests, or executing programs from the target, this must happen in a system-level sandbox: no external network, environment variables limited to an allowlist, writes only to specified temporary directories, and CPU and memory limits. Without such a sandbox, leave the lead in "pending validation" and do not execute it.
4. Do not treat speculation as a vulnerability. Without a complete source-code chain and observable results, it is not "confirmed". A missing layer of defense-in-depth counts only as a hardening recommendation, not a vulnerability.
5. Keep audit output outside the repository. By default, output goes to ~/security-audit-skill/<repo-name>/run-<number>. Only place it inside the repository if the user explicitly specifies this and it is confirmed that the directory is ignored by version control.
6. Keep secrets out of output. Do not write real keys, tokens, or environment variable values in reports or reproduction notes; use fake data and fake accounts.
7. Handle vulnerability details with care. Reports go only to the project owner; do not publicly disclose findings, and do not write them as directly exploitable attack code.

Installation

Check first:

ls ~/.claude/skills/security-audit 2>/dev/null && echo "installed" || echo "not installed"

If it is not installed, install it with the Skills CLI:

npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit

To install at user level (usable across all projects), add --global. Before installing, tell the user that this will install a third-party skill onto their computer.

Requirements: a coding Agent that supports tool calls and parallel sub-Agents; Node.js (to run the validation scripts); and the sandbox in rule 3 above.

Two Modes

Mode	When	What it does
Guided mode (default)	Security questions, targeted review, analysis of a specific lead	Uses only the relevant parts, creates no output directory, writes no files
Full audit	The user explicitly asks to "audit this codebase" or "full security review", or asks for report files	Completes all six stages and writes all report files

If unsure which mode applies, ask first, then proceed.

The Six Stages of a Full Audit

1. Reconnaissance: map the architecture, trust boundaries, and input entry points, and build a coverage checklist.
2. Hunt by coverage checklist: assign each unit to a separate Agent to hunt, and have a separate "critic" Agent look for coverage gaps.
3. Verify each finding: hand each candidate issue to a fresh Agent whose goal is to refute it.
4. Structured output: write findings.json, in three categories: confirmed (has a complete source-code chain and observable results), needs_validation (one specific fact is still missing, severity not yet set), and rejected (refuted).
5. Independent review: a new Agent re-checks the source-code basis of the final conclusions.
6. Write the report: generate REPORT.md, FINDINGS-DETAIL.md, and NEEDS-VALIDATION.md.

Audit depth comes in three levels: quick (small projects or a fast first look), standard, and deep. You can also audit only certain directories or the changes between two versions. The level only changes breadth and does not lower the evidence standard.

Common Requests

Run a security audit of this codebase, output to ~/audits/my-project

Audit only the ./src/auth directory, using the quick level

Is there an authorization bypass problem in this code? Analyze only, do not create files

Run It Multiple Times

The repository's authors say that in their testing, a single run finds only about half of the vulnerabilities that multiple runs find in total. Re-running the same project references the previous coverage checklist, fills in what was not checked, and re-verifies changed code. So for important projects, it is recommended to audit several rounds.

Notes

• It dispatches many independent sub-Agents, so time and token consumption will be considerable; try the quick level first.
• Check the evidence yourself for "confirmed" issues; do not treat "pending validation" items as vulnerabilities.
• It is an auxiliary tool and cannot replace professional manual audits; important systems still need human review before release.

Output Format

1. First state the audit scope, mode, and level, and whether it finished (if not, state the reason).
2. List confirmed issues by severity: location, impact, evidence, and minimal fix recommendation.
3. List pending leads separately, with the specific fact each one is missing.
4. State which parts were covered and which were not, and do not imply that everything was checked in one pass.
5. Give the paths to the report files.