/security - Security Audit Workflow

/​security - Security Audit Workflow

Use this skill to run a security audit workflow on sensitive code, prioritizing findings that can realistically become CRITICAL or HIGH impact.

When to Use

• The user asks for a security audit / vulnerability review ("is this secure?", "check for vulns").
• The code touches authn/​authz, payments, secrets, PII, file upload/​download, webhooks, admin actions, deserialization, or command execution.
• The user wants a scan + verification loop (audit findings → fixes → re-check).

When NOT to Use

• The user wants a general code review, debugging, refactor, or style improvements.
• The code is clearly non-sensitive (toy scripts, local-only utilities) and the user isn’t asking about security.

Defaults / Guardrails

• Report CRITICAL/​HIGH only. If none exist, explicitly report none.
• Treat "possession implies compromise" as non-finding unless you show a feasible token/​secret acquisition path.
• Prefer exploit-chain depth over breadth. Drop noise that can’t reach material impact.

For deeper triage/​prerequisite rules and consistent output formats, read:

• references/​triage-and-prereqs.md
• references/​report-templates.md

Workflow

0) Confirm Scope

Determine one of:

• Full codebase: /​security
• Area: /​security auth (or similar)
• Single file: /​security path/​to/​file
• Dependencies only: /​security --deps

1) Static Audit (Phase 1)

Goal: find and explain only CRITICAL/​HIGH issues with clear attacker prerequisites.

Prioritize:

• Injection: SQL/​NoSQL, command/​OS, template injection, SSRF, XSS.
• Authz failures: IDOR, missing checks, privilege escalation.
• Authn/​session: token validation mistakes that increase attacker capability.
• Secrets: hardcoded credentials, leaked tokens/​keys, unsafe secret handling.
• Insecure deserialization, unsafe file handling (path traversal), dangerous eval.
• Supply chain: obviously vulnerable deps or unsafe install/​build hooks.

Evidence required per finding:

• Attacker-controlled source → security-sensitive sink (show the path).
• Concrete exploit narrative and prerequisites.
• Containment + long-term remediation steps.

2) Runtime Verification (When Runnable)

If there is a runnable target, verify with minimal, safe steps.

Rules:

• Only test instances you control / are authorized to test (prefer localhost).
• Avoid DoS-like loops, mass writes, or destructive behavior.
• Prefer repo-native commands (README, Makefile, Docker, package scripts).

Verification checklist:

• Find how to run: README, Dockerfile, docker-compose, Makefile, package scripts.
• Start the service in minimal config.
• Prove impact with 1–3 deterministic requests/​steps.

3) Fix Guidance

Recommend changes that eliminate the root cause:

• Parameterize queries; avoid shell; escape/​encode; strong allowlists for URLs/​paths.
• Enforce deny-by-default authorization.
• Remove secrets from repo; use env/​secret store; rotate compromised keys.

4) Re-Verify (Phase 2)

After fixes, re-run minimal repros and any relevant security checks.

Triage Rules (Noise to Skip Unless Chained)

Skip by default unless you can chain to data loss/​auth bypass/​priv-esc with evidence:

• CORS/​OPTIONS “bypass” without protected response body or state change.
• Missing rate limiting/​lockout by itself.
• Account enumeration without a takeover/​privileged action path.
• Timing side-channels without a feasible remote measurement model.
• Swagger/​UI exposure gated to non-prod.
• Token-type confusion unless it meaningfully increases capability beyond intended flows.

If a borderline issue is showing up repeatedly, apply the stricter escalation criteria in references/​triage-and-prereqs.md.

Subagent Prompts

Phase 1: aegis (Audit)

Security audit: [SCOPE]

Find CRITICAL/​HIGH only. For each finding include:
- severity (CRITICAL/​HIGH)
- attacker prerequisites
- source → sink evidence (file/​function references)
- minimal repro steps (safe)
- remediation (containment first, then long-term)

If no CRITICAL/​HIGH exist, explicitly output: NONE.

Deprioritize noise categories unless chained to material impact.

Phase 2: arbiter (Verify)

Verify security fixes: [SCOPE]

- Re-run minimal repro steps for each previously reported CRITICAL/​HIGH
- Run the repo’s test/​build checks relevant to the changed area
- Run dependency audit appropriate to stack (e.g., npm/​pip/​go)

Output: verification report (fixed/​not fixed) and any regressions.

Flags

• --deps: dependencies-only audit
• --verify: post-fix verification run
• --secrets: prioritize secret detection and leakage paths