Find exploitable vulnerabilities in codebases

Security Audit is a structured method for auditing authorized codebases for exploitable vulnerabilities, using scoped reconnaissance, adversarial review, validation and structured reporting. It comes from the cloudflare/security-audit-skill project, is agent-neutral, and is meant for web apps, APIs, services, CLI tools, libraries and daemons. The auditor's job is to find exploitable vulnerabilities with real impact, not to list every deviation from a checklist.

The skill carries strict safeguards. It is for education or authorized security assessments only, with explicit written permission from the system owner. Before any command that probes, changes, persists on, extracts data from or tries credential access against a target, the agent must ask for the exact target, ask the user to confirm written authorization and the permitted scope, show the exact commands and their expected effect, and wait for explicit confirmation in the conversation. Without that confirmation it stays read-only and gives defensive guidance only, preferring a sandbox, disposable VM or controlled lab. Testing stays within the approved scope and avoids destructive exploitation.

Setup establishes a target and a stable target ID derived from the canonical repository path and normalized origin URL, plus an output directory (by default a run folder under ~/security-audit-skill/<target-id>/). Artifacts written there are architecture.md, REPORT.md, FINDINGS-DETAIL.md, findings.json and target.json. Prior runs count only if their manifest matches the current target exactly, and matching prior findings are used to skip known issues and aim at gaps, because one run finds only roughly half of what multiple runs find.

The workflow has six phases:

1. Recon: parallel research agents map the application's type, tech stack, comparable software and its security tradeoffs, trust boundaries, authentication and authorization, privilege separation, and an inventory of every input surface and dangerous sink, summarized in architecture.md.
2. Hunt: several general agents run in parallel, split by attack class and subsystem, each given the architecture summary, a scope, starting file paths, the hunting methodology and the validation rules. Classes include injection, access control, resource and file handling, cryptography and secrets, business logic, feature abuse and data leakage, chained attacks and trust boundaries, a wildcard, and the "obvious things". Companion files add classes for native and memory-safety targets, AI and LLM agents, HTTP-protocol and authentication systems, and client-side or browser targets.
3. Validate: duplicates are merged, then a separate agent tries to disprove each finding through exploitation, impact, baseline, mitigation and parser-behavior tests, returning confirmed or rejected with code evidence.
4. Report: REPORT.md has an honest executive summary, the identified baseline, a findings table, each finding with file path, attack scenario, impact and fix, hardening notes kept separate from findings, and positive patterns; FINDINGS-DETAIL.md gives full data flows for medium and higher findings.
5. Structured output: confirmed and rejected findings are written to findings.json following a strict schema (with intended behavior, confidence, and separate likelihood, impact and overall severity in lowercase values) and checked with a trusted JSON Schema validator already in the environment.
6. Independent verification: a fresh agent per confirmed finding checks every cited file and line, the root cause, the entry point and the remediation, returning verified, corrected or rejected, after which the prose reports are reconciled with the JSON.

Use it when asked to perform a security audit, find security bugs, do a security review or a pen-test of a codebase you own or are authorized to assess. It requires a coding agent that supports tool use and parallel sub-agents and a trusted JSON Schema validator, and it does not replace manual penetration testing or automated SAST and DAST tools.

Core principles: only report what can be exploited with a concrete scenario of who the attacker is, what they do and what they get; confirm dynamically where the target is locally buildable, and mark anything needing infrastructure as requiring deployment testing rather than confirmed; treat defense-in-depth gaps as hardening notes; and require severity to reflect both likelihood and impact. Critical means unauthenticated remote code execution, a full database dump or account takeover without credentials; high covers authenticated code execution, injection with data exfiltration, stored cross-site scripting for all users or auth bypass, and a complete defeat of an explicit permission boundary; medium covers conditional or limited-impact issues; low covers non-secret disclosure; and informational is a confirmed minimal observation.

Ten anti-patterns make audits useless: treating OWASP as a bug list, inflating defense-in-depth gaps, ignoring the deployment model, calling designed behavior a bug, padding with low findings, reporting "potential" issues without proof, ignoring what the code does well, building exploits on unverified parser or runtime assumptions, skipping business logic and creative attacks, and giving up too early.

An example request and response:

User: Audit this repository for authorization bypasses and injection paths. Keep testing local and non-destructive.
Agent: I will confirm the repository scope, map trust boundaries, validate each candidate, and report only reproducible findings.

The input is the target repository and the confirmed scope. Outputs are the report files listed above. A short report with three real findings is worth more than a long one with thirty theoretical ones, and an honest "nothing found" is valid after a serious effort.

It relies on the agent's delegation mechanism for research and general sub-agents, a trusted JSON Schema validator, and the bundled report-schema.json.

It suits security engineers, application developers and reviewers who have authorization to assess their own code and want a disciplined, evidence-based audit process that limits false positives.