What is Cloudflare Security Audit Skill?

Cloudflare Security Audit Skill is an open-source instruction set and supporting validator toolkit for security reviews by a coding agent. It organizes source inspection into reconnaissance, coverage-led hunting, candidate validation, structured output, independent record verification and reporting. The aim is to keep findings tied to a specific source revision and an explicit evidence trail.

The skill runs inside a compatible agent environment rather than a hosted Cloudflare scanning dashboard. The host supplies model access, tool use and parallel subagents. Node.js runs the supplied record and coverage validators. Executing target-controlled code additionally requires an operating-system-enforced sandbox with the controls described by the project.

Its reporting model separates confirmed findings, unresolved leads and rejected candidates. A confirmed record needs a complete source trace and a bounded observed result. An unresolved lead retains the fact that still needs validation instead of acquiring an unsupported severity label. Separate agents review discoveries and final records to challenge the original interpretation.

The reviewed source snapshot is commit c1c8a8c1471069fb0e188eeaff69b8e8db6564a8, checked October 22, 2026. The project is MIT-licensed and had no tagged release at review. This profile describes the published workflow; it does not claim that iThub has used it to establish the security of a codebase.

Key capabilities

A six-phase audit workflow The phases connect architecture mapping, hunting, candidate validation, structured records, fresh verification and final reports. They give a reviewer explicit checkpoints instead of treating a long generated narrative as the audit result. Guidance mode and full-audit mode have different scopes; loading the skill does not automatically authorize a full run.
A coverage ledger Reconnaissance produces architecture.md and coverage-ledger.json. Work is assigned from defined coverage units, with critics looking for gaps and a validator checking updates. The ledger records what was examined and what remains unresolved. It should not be interpreted as proof that every path or security property was tested.
Separate discovery and verification A fresh verifier tries to disprove each unique candidate. Later agents check final source claims, and material replacements receive further verification. This separation reduces dependence on the original investigator's reasoning. It remains an agent-based workflow with shared model and environment limitations, not an independent third-party certification.
Machine-readable finding records Findings.json uses confirmed, needs_validation and rejected verdicts under report-schema.json. The supplied validators check findings and ledger structure at required stages. A schema-valid record still needs correct source interpretation and evidence; structural validation is not itself a vulnerability reproduction.
Reports derived from records REPORT.md, FINDINGS-DETAIL.md and NEEDS-VALIDATION.md are derived from the verified records and coverage ledger. Keeping those artifacts connected helps reviewers distinguish an actionable finding from an unresolved lead. The validation and reporting guide defines the corresponding evidence boundaries.
Target-specific investigation references The repository includes references for web protocols and authentication, client-side code, memory safety, AI systems, supply chains, cloud deployment, messaging and other surfaces. They are prompts for relevant investigation, not a claim that every target needs every attack class or that a checklist alone establishes exploitability.
Explicit target-execution isolation The source requires restricted network access, an allowlisted environment, bounded resources and isolated writable scratch paths for target-controlled execution. If those controls are unavailable, the lead stays unresolved rather than running target code with ambient access. The skill describes this requirement; the operator must provide the actual sandbox.
Additive repeated reviews Later runs can use prior ledgers and findings to revisit changed source and uncovered areas. Current-source evidence remains necessary. A finding from an older revision should not silently become a confirmed result for a new commit, and an unresolved unit should not be carried forward as completed coverage.

Where Cloudflare Security Audit Skill fits

Reviewing a repository before a release

Choose an exact source revision and define the intended trust boundaries before starting the audit. Use the ledger to make coverage assignments visible and the finding records to preserve evidence. Review the unresolved report alongside confirmed issues. Release approval remains a human decision informed by the actual application and its deployment.

Investigating a specific security question

Use guidance mode for a focused question or candidate rather than automatically creating a full audit run. Load the relevant reference and narrow the required fact. The workflow specification distinguishes focused guidance from the complete six-phase process.

Turning candidate findings into reviewable work

Require each candidate to identify the relevant source path, boundary and missing or observed condition. Give a separate verifier enough context to challenge the claim. A disproved candidate belongs in the rejected record; an unavailable environmental fact belongs in needs_validation. This keeps uncertainty visible to the engineering team.

Repeating a review after source changes

Compare the new source revision with the evidence from earlier runs. Revalidate affected findings and identify new or previously uncovered units. Preserve the history without promoting stale claims. The reconnaissance guide explains how prior evidence and current coverage inform the next pass.