Security Audit Skill

Purpose

Perform a thorough, threat-model-first security audit of a codebase, producing a structured report with findings ranked by Impact x Exploitability x Exposure, mapped to CWE and OWASP categories, and (for High and Critical) supported by a concrete exploit scenario. Deliver the report as a self-contained file at the project root in the format the user chose (see "Report Format" below): HTML following references/report-template-html.md, or Markdown following references/report-template.md.

This skill is exclusively focused on security. For general code-quality auditing (concurrency, dead code, anti-patterns, performance, correctness, error handling, tests), use the sibling code-audit skill in the same plugin. The two skills can run independently or in sequence on the same codebase. If a non-security code-quality issue is encountered incidentally during this audit, note it briefly and recommend running the code-audit skill rather than analyzing it in depth here.

Effort Level

Read every line of in-scope code. Do not skim, sample, or rely on heuristics to skip files. The defining technique of this audit is source-to-sink dataflow — trace untrusted input from every entry point through the call graph to every dangerous sink, and at each step evaluate validation, encoding, authorization, and trust assumptions. Pattern matching alone misses real vulnerabilities; dataflow tracing finds them. When the scope is too large for a single pass, split work across parallel subagents (see Phase 5 for partitioning strategy).

Mindset

Audit the code as a pentester would: assume any untrusted input is hostile, assume any check can be bypassed unless proven otherwise, assume any boundary can be crossed unless validated. Defense-in-depth matters — when one layer fails, what's the next layer? Look for what is missing (a check that should exist), not only what is present (a check that's wrong). Most real-world breaches come from missing controls, mass-assignment-style overposting, broken object-level authorization, and trust placed in user-controlled fields, not from exotic exploits.

Report Format

The audit produces a self-contained file at the project root. The format determines the file extension and the template used in Phase 6. HTML is the default because it enables inline SVG trust-boundary and dataflow diagrams, severity / CWE / OWASP tag styling, collapsible Source/Sink Map entries per service, and anchor cross-references between related findings — affordances that materially improve a long security report and cannot be expressed in Markdown.