How to Audit Codebases with Cloudflare Security Audit Skill

Most automated code reviews generated by language models produce noisy checklists of generic warnings rather than verified vulnerabilities. Cloudflare open-sourced their vulnerability analysis approach as security-audit-skill, an orchestration workflow designed for coding agents. Instead of running a single scan prompt, it divides auditing tasks across isolated worker agents for architecture reconnaissance, ledger tracking, adversarial candidate disproof, and schema validation. Here is how to set up and execute a structured multi-phase audit on a local repository.

Step 1 – Install the Skill and Prepare the Runtime Sandbox

Install the skill globally with the Skills command-line utility. The tool requires Node.js to execute internal validation scripts and an isolated operating environment for sub-agents.

# Install security-audit-skill globally
npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit \
  --global

Because security audits execute dynamic probes against untrusted dependencies, build targets, and test fixtures, restrict system access before initiating a scan. Enforce strict isolation on the agent process, disable outbound internet access, and configure an explicit scratch path outside your target repository. An unspecified destination defaults to ~/security-audit-skill/<repo-name>/run-<N>. Running inside an uncontained environment risks unintended file overwrites, arbitrary script execution, or polluting your clean git working tree with ephemeral test artifacts.

Step 2 – Map Architecture and Initialize the Coverage Ledger

Start your coding agent inside the target project and trigger the workflow with a direct audit instruction. The first phase maps trust boundaries, system entry points, authentication paths, and sensitive data flows.

# Command sent to your coding agent interface
security audit this codebase, output to ~/audits/target-project

The reconnaissance phase writes a high-level system summary into architecture.md and creates coverage-ledger.json. This ledger divides the entire repository into discrete inspection units rather than relying on raw directory trees. The parent orchestrator runs an internal script, validate-coverage-ledger.cjs, to ensure the map covers every critical path without structural gaps. Every subsequent hunting task binds directly to a registered ledger item, establishing deterministic tracking throughout the rest of the audit.

Step 3 – Run Coverage-Led Hunting Across Attack Classes

In the second phase, the orchestrator spawns isolated hunter agents dedicated to specific ledger units. These hunters focus on targeted attack profiles, including memory safety, RPC protocols, web request framing, authorization bypass, and resource exhaustion.

A defense-in-depth omission is a hardening suggestion, not a vulnerability. A finding requires a verified boundary failure with practical impact.

Hunters log checked files and test vectors directly back into the ledger. A separate critic agent reviews ledger progress at regular intervals, flagging blind spots where code paths were examined too shallowly. When a hunter discovers an apparent security flaw, it generates a candidate record containing the affected source files and execution conditions, without marking the issue confirmed.

Step 4 – Validate Candidates with Adversarial Disproof Loops

Candidate flaws are passed directly to fresh verifier agents that did not participate in the initial hunt. This separation prevents confirmation bias from leaking into final reports.

# Ledger state verification command used by the orchestrator
node scripts/validate-findings.cjs findings.json

The verifier agent attempts to disprove the vulnerability candidate by identifying upstream sanitizers, network perimeter protections, or runtime invariants that stop exploitation. If the attack path fails or relies on invalid assumptions, the verifier rejects the candidate and records the exact reason. When an exploit requires dynamic execution that the local sandbox cannot safely run, the orchestrator marks the record as needs_validation alongside the specific unresolved fact. This rule prevents speculative hallucinations from entering production findings.

Step 5 – Generate Schema-Validated Findings and Artifacts

Once candidate verification completes, the skill writes structured records into findings.json and validates the file against report-schema.json. Each confirmed entry requires a complete source trace, reproducible attack steps, and concrete impact assessments.

# Validate candidate records against report schema
node scripts/validate-findings.cjs findings.json report-schema.json

The framework compiles three distinct markdown documents from the ledger data: REPORT.md for executive summaries, FINDINGS-DETAIL.md for technical remediation steps, and NEEDS-VALIDATION.md for unresolved edge cases. Because all findings adhere to an enforced JSON schema, engineers can pipe validated outputs directly into vulnerability trackers or automated continuous integration alerts without manual parsing overhead. The structured format eliminates ambiguous descriptions and produces clear, practical diffs for engineering teams.

Next steps

Inspect the output directory and triage confirmed items in REPORT.md first. For records inside NEEDS-VALIDATION.md, write targeted unit tests or integration fixtures to verify the identified boundary conditions manually. Because runs are additive and independent passes often surface complementary findings, schedule a second run against high-risk modules after initial fixes land.