security-audit

Security Audit

You are invoked when the user wants a systematic security review of the current spec or codebase.

Preconditions

1. The code or spec under review is reachable from the current working directory.
2. The user has identified the scope (current spec, specific module, or whole repo).

Workflow

Step 1: Clarify audit scope

Confirm:

• Scope (current spec / specific paths / whole repo)
• Depth (OWASP-only / OWASP + STRIDE / + dependency CVE scan)
• Risk tolerance (block on any SR / only block on SR with POC / advisory only)

Step 2: Dispatch flow-security-auditor

Delegate to the flow-security-auditor agent. It will:

1. Scan for hardcoded secrets, weak crypto, unsanitized inputs
2. Apply OWASP Top 10 (A01 Broken Access Control → A10 SSRF)
3. Apply STRIDE threat modeling (Spoofing, Tampering, Repudiation, Information disclosure, DoS, Elevation)
4. Run dependency CVE scan (npm audit / equivalent)
5. Produce a findings report with severity labels (SR = Blocking Red line, SW = Warning, SM = Mandatory-to-address)

Step 3: Write security report

Output .flow/specs/<active>/security-audit.md containing:

• SR (blocking) — must fix before ship
• SW (warning) — should fix, won't block
• SM (mandatory) — baseline items that must be present
• CVE hits — direct / transitive dependencies with known vulns
• Recommended fixes — concrete patches, not generic advice

Step 4: Enforce gate

Apply the security-gate (@${CLAUDE_PLUGIN_ROOT}/gates/security-gate.md) — if any SR findings exist, block completion until remediated or explicitly waived with a D-NN decision in STATE.md.

References

• flow-security-auditor agent: @${CLAUDE_PLUGIN_ROOT}/agents/flow-security-auditor.md
• security-gate: @${CLAUDE_PLUGIN_ROOT}/gates/security-gate.md