We Tried Cloudflare's New Security-Audit Skill for Claude Code. Here Is What It Actually Checks.

Cloudflare open-sourced security-audit-skill this month — a coding-agent skill that turns Claude Code (or any agent supporting the Agent Skills standard) into a structured security auditor, with independently verified, machine-readable findings. It crossed 16,000 GitHub stars within days. Here’s what it actually does, walked through step by step, rather than just repeating the pitch.

What it is, precisely

This isn’t a linter and it isn’t a single prompt asking an agent to “find bugs.” It’s a six-phase orchestration: reconnaissance, coverage-led hunting, candidate validation, structured output, independent record verification, and target-neutral reporting. The phase names matter more than they sound like marketing — each one exists to close a specific failure mode of naive “ask the AI to find vulnerabilities” approaches.

Installing it

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

The --global flag installs it once for all your projects rather than per-repository. Run npx skills --help if you need agent-specific install flags or a non-interactive setup for CI.

Running an audit

Point your coding agent at the codebase you want checked, then ask for a security audit in plain language — “find vulnerabilities,” “pen-test this code,” and similar phrasing all trigger it automatically. The skill activates on trigger-match rather than needing an explicit slash command, which matters for teams where not everyone remembers exact tool syntax.

It runs in one of two modes depending on what you actually asked for:

• Guidance mode — for security questions and focused vulnerability work, without generating report artifacts. Use this for “is this auth check sufficient” type questions during normal development.
• Full audit mode — triggered by a direct codebase audit or pen-test request. This is the six-phase process, and it produces actual report files.

In full audit mode with no output directory specified, results land in ~/security-audit-skill/<repo-name>/run-<N> by default — outside your repository. That default is deliberate: the workflow only writes inside your target repository if you explicitly point it at a directory your version control already ignores, which keeps audit scratch files from accidentally getting committed.

What the six phases actually do

Walking through them in order, since this is the part that differentiates it from a single-pass AI code review:

1. Reconnaissance — the agent maps the codebase structure, dependencies, and attack surface before looking for anything specific. This is the step naive approaches skip, and it’s why they tend to miss context-dependent vulnerabilities.
2. Coverage-led hunting — rather than pattern-matching against a fixed vulnerability checklist, this phase is driven by ensuring the mapped surface from phase one gets actually examined, not just the parts that look obviously suspicious.
3. Candidate validation — flagged issues get checked against being actually exploitable in context, not just structurally resembling a known bad pattern. This is the step that should reduce false positives relative to a plain static-analysis pass.
4. Structured output — findings get formatted as machine-readable records, not prose paragraphs — the detail that makes “machine-readable findings” in the project’s own description literal rather than marketing language.
5. Independent record verification — a separate verification pass checks the structured findings, functioning as a check on the checker rather than trusting the first pass’s own confidence score.
6. Target-neutral reporting — the final report is generated without framing that presumes guilt or innocence going in, aiming for findings stated as evidence rather than a verdict already decided.

A coding agent whose model supports tool use and parallel sub-agents is required — this isn’t a single-model, single-pass tool, which is part of why it needs real orchestration rather than one long prompt.

What the output actually looks like

Since “machine-readable findings” is a specific claim, it’s worth showing roughly what that means in practice. Each finding in the structured output phase is emitted as a discrete record rather than a paragraph — conceptually shaped like:

{
  "finding_id": "...",
  "phase_detected": "coverage-led-hunting",
  "severity": "...",
  "location": "path/to/file:line",
  "validated": true,
  "verification_notes": "...",
  "evidence": "..."
}

The exact schema will vary by version — check the repository directly for the current format — but the structural point holds: because findings are structured records rather than free text, they can be diffed between runs, filtered by severity or validation status, and fed into other tooling (a ticket tracker, a CI gate, a dashboard) without a human having to parse prose first. That’s the practical payoff of phases 4 and 5 existing separately from the hunting phase — you get a result you can automate against, not just read.

Common questions before you run this

Does it modify my code automatically? No — this is an audit and reporting tool. It identifies and validates findings; remediation is a separate step you or your team perform afterward. Don’t confuse this with an auto-fix tool.

How long does a full audit take? Not officially specified, and it will vary heavily by codebase size and the parallel sub-agent capability of your specific model — this is exactly the kind of number worth measuring on your own repo rather than trusting a general estimate, given how much it depends on your specific setup.

Can I run this in CI? The npx skills --help output includes non-interactive options, suggesting CI use is a supported path, but treat this as an early-adopter integration rather than a documented, battle-tested CI pattern — verify behavior in a non-blocking pipeline stage before making it a merge gate.

What happens to findings that fail validation in phase 3? They should be excluded from the final structured output and report — that’s the entire purpose of the candidate validation phase existing as a distinct step rather than reporting every raw pattern match from the hunting phase.

Where this fits next to what already exists

Cloudflare is explicit that this covers infrastructure-adjacent code review, and pairs it with /security-review, Claude Code’s native command, which handles application-layer concerns — SQL injection, XSS, authentication, dependency issues. The stated division: /security-review for code, security-audit-skill for the surrounding infrastructure and configuration layer. Running both, rather than treating either as a complete substitute for the other, is the intended use.

Also worth knowing: Cloudflare separately publishes a broader cloudflare/skills repository — platform-specific skills for Workers, Pages, KV/D1/R2 storage, the Agents SDK, and infrastructure-as-code via Terraform and Pulumi. The security-audit skill is the one that went viral, but it’s part of a wider pattern of vendors shipping agent skills as a distribution channel for platform expertise, not a one-off release.

What we’d actually flag before you run this on production code

• This is an early, fast-moving space. A 16,000-star repository a few weeks old has real usage behind it, but nowhere near the multi-year track record of established static-analysis tooling (Semgrep, CodeQL, and similar). Treat findings as a strong first pass, not a replacement for an established scanner in a compliance-sensitive pipeline.
• “Independently verified” describes the internal verification phase, not third-party audit of the skill itself. The tool verifying its own findings against itself is a meaningfully different claim than an external security firm having audited the skill’s own logic. Worth keeping that distinction clear when describing results to a client or your own leadership.
• Requires real model capability. Parallel sub-agents and genuine tool use aren’t available on every model tier — check your agent’s actual capability before assuming this runs as described.

The practical takeaway

If you’re already running Claude Code and have any infrastructure-as-code or platform configuration you haven’t had formally reviewed, this is a low-cost first pass worth trying — the install is a single command, and worst case you learn where your own review process has gaps. Treat its output as a lead-generation step for a human reviewer to confirm, not a final verdict, especially anywhere the finding would justify a production change on its own.

Official reference: Cloudflare’s security-audit-skill repository on GitHub, current as of September 2026. Star counts and adoption figures for fast-moving open-source projects change quickly — check the repository directly for current numbers before citing them elsewhere.