Who security-audit-skill is for#
Security engineers auditing internal codebases
Run a structured six-phase audit without sending code to a third-party scanner. The coverage ledger tracks which attack surfaces have been reviewed, and the `needs_validation` file gives follow-up items an exact unresolved fact rather than a vague note. Multiple runs extend coverage incrementally instead of repeating the full audit from scratch.
Skip if:
Skip if the target codebase changes so frequently that prior ledgers become stale before the next run. The additive coverage model works best when the repo is stable enough between runs for prior evidence to remain valid.
Platform teams reviewing AI-backed services
The AI-AND-LLM.md attack class covers prompt injection, agent/tool misuse, and output-handling vulnerabilities. Teams shipping services that call LLMs or run coding agents can target these surfaces specifically, as these attack classes are not well covered by rule-based static analysis tools.
Skip if:
Skip if the service contains no LLM integration or agent toolchain. The AI-specific attack classes add no unique value over a general security review for a traditional stack; the general attack classes in ATTACK-CLASSES.md cover that case.
Developers running pre-submission vulnerability checks
Clone the repo and point the agent at the repository before submitting a pull request. The skill runs in guidance mode for focused vulnerability questions without requiring full report artifacts, which suits a quick pre-submission check on specific files or modules.
Skip if:
Skip if the change is purely documentation or configuration with no code paths. Guidance mode is most useful when the change touches authentication, authorization, input handling, or inter-service calls.
Red teams building repeatable audit workflows
Multiple runs against the same target are additive: the skill uses prior ledgers to target gaps and revalidate changed source. This makes nightly automated audits practical, with each run building on prior coverage rather than restarting from scratch.
Skip if:
Skip if your organization requires findings in a standard interchange format such as SARIF or CycloneDX. The skill outputs REPORT.md, FINDINGS-DETAIL.md, and a findings.json in its own three-verdict schema, not a standard security report interchange format.
The problem it solves#
Security audits are expensive to run manually and easy to shortcut. Code reviewers focus on familiar bug classes and miss attack surfaces that span trust boundaries, deployment configurations, and AI-agent toolchains. Automated scanners improve coverage but cannot reason about exploitability. A tool that flags every deviation from a security checklist treats defense-in-depth gaps as vulnerabilities and buries real findings in noise.
The harder challenge is validation. A single agent that finds and confirms its own candidates is unreliable: confirmation bias, incomplete context, and the absence of adversarial pressure all inflate the confirmed count. Teams that outsource audits to commercial vendors receive a report, not a reproducible artifact tied to current source. When the code changes, the audit starts over from nothing.
How it solves it#
Six-Phase Audit Workflow
Structures the audit into reconnaissance, coverage-led hunting, candidate validation, structured output, independent record verification, and target-neutral reporting. Each phase produces artifacts the next phase consumes: an `architecture.md` file, a `coverage-ledger.json`, and a `findings.json` with `confirmed`, `needs_validation`, and `rejected` verdicts. Validators run automatically after each ledger update and after each findings write.
Adversarial Candidate Validation
Every unique candidate finding is handed to a fresh verifier agent that did not discover it, and that verifier's job is to disprove the claim. Only findings that survive adversarial scrutiny reach `confirmed` status. A finding that cannot be fully resolved becomes `needs_validation` with an exact unresolved fact attached and no severity assigned until the fact is resolved.
Coverage-Led Hunting with Additive Runs
Hunters are assigned from units in the coverage ledger, tracking which attack surfaces have been inspected. Coverage critics find gaps. Multiple runs against the same repo are additive: prior ledgers and findings target gaps, revalidate changed source, and carry forward current-source evidence. Cloudflare's own test data shows a single run finds roughly half the vulnerabilities that repeated runs find in total.
Attack-Class Files Across 11 Specialized Domains
Separate prompt files cover memory safety and binary targets, AI/LLM attack surfaces (prompt injection, agent/tool misuse, output handling), web and auth protocols, client-side and browser targets, supply chain and CI, cloud and deployment, RPC and messaging, resource exhaustion, data isolation, and desktop/mobile IPC. Each file is usable independently for focused audits on specific surfaces.
Machine-Readable Findings with Schema Validation
Findings write to `findings.json` and are validated against `report-schema.json` in Phase 4 and again after every Phase 5 replacement. Zero-dependency Node.js validators (`validate-findings.cjs`, `validate-coverage-ledger.cjs`) run automatically. Final reports (`REPORT.md`, `FINDINGS-DETAIL.md`, `NEEDS-VALIDATION.md`) are derived from the verified records, not reinterpreted from raw candidates.
Target-Neutral Reporting from Verified Records
The reporting phase derives output strictly from the verified findings and the coverage ledger. `NEEDS-VALIDATION.md` captures unresolved leads with their exact unresolved fact, so a future run picks them up rather than re-discovering them. Each confirmed finding carries a complete source trace and a bounded observed result, separating evidence from interpretation.
Strengths and trade-offs#
Strengths
- MIT License with Zero Infrastructure OverheadMIT licensed with no vendor contract required. The skill runs inside your existing coding agent; there are no per-scan fees, no data transmitted to a third-party API, and no SLA tied to a vendor. You pay for agent API calls, which you control, and nothing else.
- Additive Multi-Run CoverageEach audit run extends coverage rather than restarting it. The coverage ledger tracks which attack surfaces have been inspected, and subsequent runs target gaps and revalidate changed source. Cloudflare's own test data shows a single run finds roughly half the vulnerabilities that repeated runs find in total.
- Provenance on Every Finding`confirmed` findings carry a complete source trace and a bounded observed result. `needs_validation` records carry an exact unresolved fact and no severity, so you never inherit a severity rating without the reasoning that produced it. `rejected` records explain why each candidate was disproved, preventing the same candidate from being re-raised in future runs.
- No Cloudflare Infrastructure DependencyDespite being authored by Cloudflare and seeding their internal vulnerability discovery pipeline, the skill has no dependency on Cloudflare products. It runs on any coding agent with tool use and parallel sub-agent support, including fully self-hosted agent environments.
Trade-offs
- -Requires OS-Enforced Sandbox for Full CoverageWithout an OS-level sandbox that disables external networking, sanitizes the environment, enforces resource limits, and restricts writes to assigned scratch paths, the workflow cannot safely execute target-controlled builds, tests, or browsers. Without those controls, leads that require code execution stay `needs_validation` rather than moving to `confirmed`. The sandbox setup is not included in the skill itself and requires separate infrastructure work.
- -Audit Depth Depends on the Agent's ModelThe skill is a prompt-based workflow, not a static analysis engine. Audit depth depends on the model's ability to reason about trust boundaries, chase multi-step attack chains, and recognize subtle control-flow issues. The README requires a model with tool use and parallel sub-agent support; a model that struggles with long-context reasoning will produce shallower coverage than a stronger one.
- -Node.js Required for Schema ValidatorsThe zero-dependency `validate-findings.cjs` and `validate-coverage-ledger.cjs` validators require Node.js. Agent environments without Node.js cannot run schema validation automatically, which means Phase 4 and Phase 5 validation steps must be handled manually or skipped.
security-audit-skill vs alternatives#
security-audit-skill vs Snyk Code
Snyk Code is a static application security testing (SAST) tool that scans source code against a vulnerability database and rule set. security-audit-skill takes a different approach: it runs isolated AI agents through six structured phases, with each candidate finding independently verified by a separate agent that did not discover it.
| Feature | security-audit-skill | Snyk Code |
|---|---|---|
| License | MIT | Proprietary |
| Self-hosting | Yes (runs in your coding agent) | No |
| Analysis method | Multi-agent reasoning with adversarial validation | Static analysis with rule-based detection |
| Finding format | findings.json with confirmed/needs_validation/rejected verdicts | Dashboard and IDE plugin findings |
| AI/LLM attack coverage | Dedicated attack-class files | Limited coverage for LLM-specific vulnerabilities |
| Pricing | Free (agent API costs only) | Paid; free tier with limited projects |
Snyk Code is the better choice for teams that need fast, continuous scanning integrated into CI/CD without agent infrastructure. It surfaces known CVEs and common patterns with low setup friction. security-audit-skill is better when you need adversarial validation on each finding, provenance for every confirmed vulnerability, or coverage of AI-specific attack surfaces like prompt injection that rule-based scanners do not model.
security-audit-skill vs GitHub Advanced Security (CodeQL)
GitHub Advanced Security includes CodeQL, a semantic code analysis engine that queries code as data. Like Snyk Code, it is a rules-and-queries engine that surfaces findings against a known vulnerability pattern set.
| Feature | security-audit-skill | GitHub Advanced Security |
|---|---|---|
| License | MIT | Proprietary (CodeQL engine) |
| Self-hosting | Yes | GitHub-hosted; CodeQL CLI available |
| Analysis method | Multi-agent AI reasoning | Semantic code analysis queries |
| Finding verification | Independent agent verifier per finding | No adversarial validation step |
| Attack-class breadth | 11 specialized domain files | Query packs for OWASP Top 10 and common CVEs |
| Cost | Free (agent API costs) | Paid add-on for private repositories |
GitHub Advanced Security is the right choice for teams already on GitHub who need integrated pull request scanning, known CVE detection, and compliance reporting. security-audit-skill is more useful when you want multi-run additive coverage, findings with explicit source traces, or an audit of attack surfaces that CodeQL queries do not cover (supply chain configuration, AI-agent toolchains, and resource exhaustion across multi-tenant boundaries).
Quick start#
Install the skill by cloning the repository; your coding agent reads the skill files directly.
```bash
git clone https://github.com/cloudflare/security-audit-skill
```What it's built on#
- Languages
- JavaScript
FAQ#
What coding agents are compatible with security-audit-skill?
Any coding agent whose model supports tool use and parallel sub-agents. The README does not name specific agent products; it requires those two capabilities plus Node.js in the environment for the findings and coverage-ledger validators to run automatically.
Does security-audit-skill require a Cloudflare account?
No. The skill has no dependency on Cloudflare infrastructure or products. It was authored by Cloudflare and seeded their internal vulnerability discovery pipeline, but the published version is a standalone coding-agent skill that runs in any compatible agent environment.
What is the difference between confirmed, needs_validation, and rejected findings?
confirmed findings have a complete source trace and a bounded observed result from the independent verifier. needs_validation findings carry an exact unresolved fact, typically something requiring code execution in a sandbox, and no severity rating until resolved. rejected findings record why a candidate was disproved, preventing re-discovery in future runs.
Is a sandbox required to run the skill?
A sandbox is required for findings that need to execute target-controlled builds, tests, browsers, emulators, fuzzers, or fixtures. Without it, those leads stay needs_validation. Static source analysis and architecture mapping work without a sandbox. The README specifies that the sandbox must disable external networking, use a sanitized allowlisted environment, enforce resource limits, and allow writes only to assigned scratch paths.
How is security-audit-skill licensed?
MIT. You can run it on your own infrastructure, modify it, and use it commercially without restriction. The MIT license places no limit on self-hosted or internal commercial use.
Similar open-source tools#
tailcat
Encrypted tunnels between machines, no account or IP needed
hysteria
Fast and censorship-resistant proxy solution
Omnara
Open-source agent deployment API. Self-host or use Omnara Cloud.
ASC
Zero-overhead Android decompiler for mobile security researchers
opendisplay
Turn any iPhone, iPad, or spare Mac into a free second Mac monitor
flowsint
Self-hosted graph tool for OSINT and cybersecurity investigations