Cloudflare's security-audit skill gained 2,428 GitHub stars in one day, three months after the company published the workflow that seeded it. The repository is a six-phase set of instructions for coding agents: map a codebase, hunt along recorded coverage units, challenge each candidate, and keep unsupported claims out of the confirmed pile. That procedural focus is the useful part of the sudden attention.
The daily gain is a community-interest signal, not a test result. The GitHub page showed 18,200 stars and roughly 1,000 forks when checked, yet those counters say nothing about missed bugs or false alarms. They do show that developers are looking for something more disciplined than asking a general coding agent to "find security issues" and accepting the first plausible answer.
The unit of work is an evidence record
The current README divides a full audit into reconnaissance, coverage-led hunting, candidate validation, structured output, independent record verification, and reporting. Reconnaissance produces an architecture map and a JSON coverage ledger. Hunters then receive specific units of work instead of roaming through the repository until their context fills up.
A suspicious code path does not become a finding at that point. The workflow requires a fresh verifier to try to disprove it. Surviving records go into findings.json as confirmed, needs_validation, or rejected, with a JSON schema and two Node.js validators checking the findings file and coverage ledger. Reports are generated from those records after another source check, which reduces the chance that polished prose drifts away from the evidence.
Installation is one command through the Skills CLI:
+npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit
+```
For readers deciding whether to try it, [our review of security-audit-skill covers the setup reality](https://mrkeyoor.com/repos/security-audit-skill/). The [project requirements](https://github.com/cloudflare/security-audit-skill) say a full run needs a tool-using model with parallel subagents, Node.js, and an OS-enforced sandbox. A security question can invoke a narrower guidance mode, while an explicit codebase audit activates the complete workflow and writes report artifacts outside the target by default.
The evidence contract is more specific than a checklist. Cloudflare's [published skill instructions](https://github.com/cloudflare/security-audit-skill/blob/main/skills/security-audit/SKILL.md) require the agent to identify the lower-trust actor, accepted input, intended control, crossed boundary, affected resource, and observed result. A missing header or second defensive layer is a hardening note when another control still blocks the attack. Severity belongs only on a demonstrated boundary failure.
## Independent verification has a narrow meaning
The repository's claim of "independently verified" refers to separation inside the [agent workflow](https://github.com/cloudflare/security-audit-skill). A hunter cannot validate its own candidate. A fresh agent checks the source trace and bounded result, and another fresh pass checks final records before the report is written. If a record changes materially during that last pass, the replacement receives another verifier.
This setup prevents one agent from discovering a theory, becoming attached to it, and grading its own work. It does not turn the output into an external security audit or a third-party certification. Two fresh contexts can still inherit the same model's blind spots. Cloudflare's [account of its internal vulnerability harness](https://blog.cloudflare.com/build-your-own-vulnerability-harness/) says its fleet system swaps models across stages because different models find different shares of the bugs. The public skill is agent-neutral, so that choice remains with the user.
The [hunting material](https://github.com/cloudflare/security-audit-skill) also reaches beyond familiar web flaws. Companion files cover memory safety, browser trust, AI prompt injection, release pipelines, cloud configuration, messaging protocols, data isolation, and local IPC. Each area is tied back to the coverage ledger. That matters because a report with five convincing findings can still be a weak audit if whole subsystems were never assigned.
Mechanical validation has a clear limit. The Node scripts can reject malformed records or inconsistent ledger state. They cannot decide whether a claimed exploit is true. [Cloudflare's blog](https://blog.cloudflare.com/build-your-own-vulnerability-harness/) makes the same distinction when it describes schema checks as mechanical rather than correctness checks. Truth still depends on source evidence, a bounded reproduction where safe, and the independent review step.
## The safety rules decide what can be confirmed
Running untrusted project code is where an automated audit can create a new incident. The [skill](https://github.com/cloudflare/security-audit-skill/blob/main/skills/security-audit/SKILL.md) therefore permits target-controlled builds, tests, fuzzers, browsers, and fixtures only inside an OS-enforced sandbox. External networking must be disabled, the environment must start empty and receive only allowlisted values, the target and toolchain stay read-only, and the process can write only to an assigned scratch directory. Resource and time limits are mandatory.
The [skill instructions](https://github.com/cloudflare/security-audit-skill/blob/main/skills/security-audit/SKILL.md) also prohibit dependency downloads, production probes, live identities, shared services, and other users' data. Tests use dummy principals and stop at the smallest effect that proves the boundary failure, such as an unauthorized dummy record or sanitizer finding. If the platform cannot enforce every control, the agent must avoid executing the target and record the lead as `needs_validation`.
That refusal changes the tone of the final report. Under the [published rules](https://github.com/cloudflare/security-audit-skill/blob/main/skills/security-audit/SKILL.md), a deployment-dependent theory cannot receive a speculative severity score. Missing proxy settings or identity policy outside the repository must be named as the exact unresolved fact. The report may look less dramatic, but a maintainer can see which claim is proved, which one needs an owner-observed check, and which candidate failed validation.
The same discipline applies to scope. The [default standard profile](https://github.com/cloudflare/security-audit-skill/blob/main/skills/security-audit/SKILL.md) records planned, covered, deferred, blocked, and out-of-scope units. Quick runs are labeled partial. Prior results can guide a new run only after the relevant source is checked again. The instructions explicitly forbid presenting one pass as exhaustive, and the README says Cloudflare's test runs found roughly half as many vulnerabilities in a single run as repeated runs found in total. That is Cloudflare's own measurement, not an independent benchmark.
## How the public skill differs from Cloudflare's fleet system
[Cloudflare's June 18 post](https://blog.cloudflare.com/build-your-own-vulnerability-harness/) describes an earlier seven-stage skill of about 450 lines. It added a final ingest step after verification and became the starting point for a fleet-wide harness. The current public repository groups its work into six phases and ends with target-neutral local reports. Its files are Markdown playbooks, a JSON schema, and zero-dependency Node validators, rather than the database-backed service Cloudflare runs internally.
The distinction affects expectations. [Cloudflare says](https://blog.cloudflare.com/build-your-own-vulnerability-harness/) the internal system took about six weeks to expand across 128 repositories, with persistent state, deduplication, cross-repository tracing, and worker pools that can reach 200 processes. The company built those pieces after single-session runs hit context exhaustion, lost work after crashes, and could not follow trust boundaries between repositories. Installing the public skill does not install that infrastructure.
The [repository](https://github.com/cloudflare/security-audit-skill) still packages several useful decisions from that larger system. Findings have stable records instead of living only in prose. Coverage gaps remain visible. The verifier did not originate the candidate it is judging. Those constraints can make an ordinary coding agent produce an audit trail that a maintainer can inspect, even when the team never builds a fleet scanner.
## What to watch in the next revisions
The [README](https://github.com/cloudflare/security-audit-skill) publishes tests for its JSON and coverage-ledger validators, but it does not give a precision or recall score for vulnerability detection. A useful public evaluation would pair known vulnerable fixtures with clean controls, then report missed flaws and false positives across named models. That would test the procedure rather than the formatting around it.
Until then, teams trying the [skill](https://github.com/cloudflare/security-audit-skill/blob/main/skills/security-audit/SKILL.md) should retain the reviewed commit, model and agent version, coverage ledger, rejected candidates, and unresolved records beside each report. A result containing only severe findings deserves extra scrutiny because this workflow is designed to produce rejection and uncertainty too. The 2,428-star day measures appetite. The next meaningful number is how often independent verification changes or removes a hunter's claim.