# Cloudflare security-audit-skill: A Six-Phase Coding-Agent Workflow for Security Audits

> The security-audit-skill is a MIT-licensed coding-agent skill from Cloudflare that orchestrates isolated sub-agents through six phases, from reconnaissance to verified reporting. It produces machine-readable findings with three verdict categories and is designed to add coverage across multiple runs rather than deliver a single definitive pass.

**cloudflare/security-audit-skill** — A coding-agent skill for multi-phase security audits with independently verified, machine-readable findings

- Repository: https://github.com/cloudflare/security-audit-skill
- Stars: 23,090 · Forks: 1,347
- Language: JavaScript
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/cloudflare-security-audit-skill

## What the Security-Audit-Skill Does and Who It Is For

The security-audit-skill is a coding-agent skill that turns a compatible agent into a structured security auditor. It originated inside Cloudflare as the starting point for their vulnerability discovery harness, described in their engineering blog post titled Build your own vulnerability harness. The harness grew into a multi-stage, fleet-wide system; this repository is the single-repo starting point it was developed from.

The skill targets engineering teams that already have a coding agent with tool use and parallel sub-agent support and want to add a repeatable security audit workflow to it. It is not a standalone scanner or a GUI-based auditing product. Its value is in the orchestration logic: it sequences isolated agents through distinct phases, prevents a finding agent from also verifying its own findings, and produces machine-readable output that accumulates across runs.

Installing the skill with the Skills CLI attaches it to your existing agent. The skill then activates automatically when a request matches its trigger phrases, such as security audit this codebase, find security vulnerabilities in a path, or pen-test the code.

## The Six Phases from Reconnaissance to Reporting

The audit runs in six sequential phases, each carried out by isolated agents.

Phase 1 is reconnaissance. The agent maps architecture, trust boundaries, input surfaces, prior evidence, and deterministic coverage. It writes the results to architecture.md and coverage-ledger.json. The parent validates the ledger after this phase using validate-coverage-ledger.cjs.

Phase 2 is coverage-led hunting. Isolated hunters are assigned from ledger units. Each hunter records its checks, and coverage critics review the results to identify gaps in what was examined.

Phase 3 is candidate validation. Every unique candidate finding goes to a fresh verifier agent that has not seen the original hunting work. That verifier attempts to disprove the finding rather than confirm it. The adversarial framing is a deliberate design choice: the agent that checks a finding is never the agent that found it.

Phase 4 writes structured output. Findings are classified as confirmed, needs_validation, or rejected and written to findings.json. The parent validates findings.json against report-schema.json using validate-findings.cjs.

Phase 5 is independent record verification. Fresh agents verify final source claims. Any finding that undergoes a material replacement receives another independent verifier, and the parent reruns validate-findings.cjs.

Phase 6 produces target-neutral reporting. The workflow derives REPORT.md, FINDINGS-DETAIL.md, and NEEDS-VALIDATION.md from the verified records and coverage ledger, not from the agents' raw notes.

## Installing and Running the Skill

Install the skill using the Skills CLI:

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

For a user-level installation that is available to all projects on the machine, add the --global flag:

```bash
npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit \
  --global
```

The README notes that npx skills --help covers agent-selection and non-interactive options.

Once installed, start your coding agent in or pointed at the codebase you want to audit and ask it to run a security audit. The skill activates on trigger phrases. A full audit request uses the complete six-phase workflow. Security questions and focused vulnerability work use a guidance mode unless you explicitly request report artifacts. In full audit mode, an unspecified output directory defaults to ~/security-audit-skill/<repo-name>/run-<N>.

The skill writes inside the target repository only when you explicitly select a directory that version control ignores. By default, output goes to the path above.

## The Three Finding Verdicts and What Each Means

The findings.json file uses three distinct verdict categories, each with a precise definition.

A confirmed finding has a complete source trace and a bounded observed result. The README defines this as an established boundary failure, not a theoretical one. Only findings that a verifier has reviewed and that have a grounded source reference reach this status.

A needs_validation finding has an exact unresolved fact and no severity. It represents a lead where the verifier could not confirm or disprove the candidate from source. The workflow retains the precise description and the unresolved question so that a future run can revisit the specific gap.

A rejected finding records a candidate that the verifier disproved. Rejection is tracked rather than discarded because retaining it prevents a future hunter from spending time on the same lead again.

The README states four principles that guide these verdicts: only confirm established boundary failures; use adversarial validation so the verifier is never the finder; require impact evidence for severity, not just deviation from a checklist; and treat defense-in-depth gaps as hardening notes rather than vulnerabilities when an outer layer already blocks the attack.

## What the Skill Cannot Do Without a Proper Sandbox

The skill requires an OS-enforced sandbox for any lead that involves executing target-controlled code, running tests, launching processes, or operating browsers, emulators, fuzzers, or fixtures. The sandbox must disable external networking, use a sanitized allowlisted environment, enforce resource limits, and allow writes only to assigned scratch paths.

Without these controls, the workflow classifies the relevant lead as needs_validation rather than executing the target code. That is a conservative design: it avoids giving a lead a confirmed verdict when the execution environment is not controlled. Teams running the skill without a sandbox will see more needs_validation verdicts and fewer confirmed ones.

The skill also requires Node.js for the two zero-dependency validators: validate-findings.cjs and validate-coverage-ledger.cjs. These run after each phase that produces or updates structured output, and the parent agent reruns them after every material replacement in Phase 5. If Node.js is not available, the validators cannot run and the structured output cannot be verified.

The README notes that the repository does not ship the full multi-stage, fleet-wide system Cloudflare uses internally. This repository is the single-repo starting point; the harness that evolved from it is not public.

## How Multiple Runs Improve Coverage Over Time

The skill is designed for iterative use. The README states that in test runs, a single audit found roughly half of the vulnerabilities that repeated runs found in total. Multiple runs are additive: each run uses prior ledgers and findings to target gaps, revalidate changed source, and carry forward current-source evidence without treating stale or unresolved work as covered.

The coverage ledger tracks which architectural units were hunted and what was checked. When a second run starts, it reads the existing ledger and directs hunters toward untested areas rather than repeating work on units that already have coverage. Changed source in areas that were previously marked covered is flagged for revalidation.

This design has an implication for adoption: a team that runs the skill once and reviews only the confirmed findings is seeing a partial picture. The needs_validation entries from earlier runs are the starting point for the next run, not a closed list. Teams that build the skill into a recurring process get cumulative coverage; teams that use it once get a first-pass snapshot.

## Conclusion

The skill is the right tool for engineering teams that run a coding agent with parallel sub-agent support, a Node.js runtime, and an OS-enforced sandbox. Without the sandbox, the workflow keeps target-controlled code execution leads as needs_validation rather than confirmed. A single run finds a subset of the vulnerabilities that repeated runs discover in total, so teams should plan for iterative use. The last push was on 2026-09-14, and the project carries an MIT license with no additional usage restrictions beyond what that license states.

## FAQ

### Does the security-audit-skill work with any coding agent?

No. The skill requires a coding agent with a model that supports tool use and parallel sub-agents. It also needs Node.js for the findings and coverage-ledger validators, and an OS-enforced sandbox for target-controlled code execution.

### What output files does a full security-audit-skill run produce?

A full audit run produces architecture.md, coverage-ledger.json, findings.json, REPORT.md, FINDINGS-DETAIL.md, and NEEDS-VALIDATION.md. The output directory defaults to ~/security-audit-skill/<repo-name>/run-<N> unless you specify a different path.

### What does the needs_validation verdict mean in findings.json?

A needs_validation entry has an exact unresolved fact that the verifier could not confirm or disprove from source, and it carries no severity rating. It represents a lead that a future audit run should revisit rather than a finding that is confirmed or dismissed.

## Sources

- [cloudflare/security-audit-skill on GitHub](https://github.com/cloudflare/security-audit-skill)
- [Issues](https://github.com/cloudflare/security-audit-skill/issues)
- [License: MIT](https://github.com/cloudflare/security-audit-skill/blob/main/LICENSE)
- [README](https://github.com/cloudflare/security-audit-skill/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cloudflare-security-audit-skill
