audit

name

audit

description

Use when running a full security audit of an arbitrary source code repository, especially large, complex, multi-component, distributed, or non-standard architectures. Defines a 10-phase security audit methodology combining advisory intelligence, patch bypass analysis, knowledge base construction, baseline and custom SAST, spec gap analysis, deep bug hunting, false positive elimination, variant analysis, and final reporting with realistic PoC construction. Triggers on "audit this repo", "run a full security audit", "find vulnerabilities in this codebase", "check for security issues", "is this secure?", "run the security agents", or any request combining advisory regression, SAST, and manual review.

Audit — Full Security Audit Methodology

10-phase security audit methodology for arbitrary source code repositories. Each phase defines what to analyze and what to produce. Orchestration (branching, state management, agent dispatch) is handled by the plugin commands.

When to Apply

• Full security audit of a repository
• Advisory regression check combined with static analysis
• Deep vulnerability research on a specific codebase
• Large or unusual architectures where default SAST modeling is likely incomplete
• "Run the security agents" / "audit for vulnerabilities" / "is this secure?"

Idempotency & Resumption

Before executing any phase, apply these rules to avoid redundant work:

• Skip completed phases: if the expected KB sections already exist and neither the codebase nor the threat-model inputs have fundamentally changed, reuse the existing content and mark the phase skipped.
• Re-audit as KB update: for re-audits, piolium/attack-surface/knowledge-base-report.md from the previous run is the starting knowledge base. Do not regenerate it from scratch. Load it, diff the codebase against the commit field of the last completed entry in piolium/audit-state.json, and update only the sections whose source inputs changed. Mark unchanged sections with . Documentation-only changes require no re-audit; changes to auth, core business logic, or attack-surface components invalidate the Static Analysis Summary and Phase 10 Addendum (, written by the Review Chambers) sections at minimum.