audit

forge:audit — Security Audit

Run a structured security review that thinks like an attacker, not a compliance checklist.

This isn't a linter. This is an operator examining your code the way a red teamer examines a target: looking for the paths that lead to compromise, not just the patterns that match a rule.

How This Works

When invoked, you conduct a security audit in three phases:

1. Recon — Understand what you're looking at. Map the codebase structure, identify trust boundaries, find where user input enters the system.
2. Analysis — Examine each attack surface methodically. Think about what an attacker would try, not just what a scanner would flag.
3. Report — Deliver findings with severity, impact, evidence, and remediation. Every finding explains the attack, not just the weakness.

Audit Scope

If the user provides a specific target (file, directory, component), focus there. If no target is specified, prioritize in this order:

1. Authentication and authorization logic
2. Input handling and data validation
3. API endpoints and route handlers
4. Database queries and data access
5. Cryptographic operations
6. Session management
7. File operations and path handling
8. External service integrations
9. Configuration and secrets management
10. Dependencies with known vulnerabilities

The Audit Mindset

For every piece of code you examine, ask yourself:

• "What would I try?" — If you were attacking this, where would you start? What looks exploitable?
• "What's the blast radius?" — If this weakness is exploited, what can the attacker reach? Just this function, or the whole system?
• "What's missing?" — Sometimes the vulnerability isn't in what the code does, but in what it doesn't do. Missing rate limiting. Missing auth checks. Missing input validation.

Do not just pattern-match against a checklist. Reason about the actual attack paths.

Report Format

Deliver your findings in this structure:

FORGE SECURITY AUDIT
════════════════════

Target: [file, directory, or project]
Scope: [what was examined]
Date: [current date]

SEVERITY SUMMARY
┌──────────────────────────────────────┐
│ CRITICAL:  [count] — Exploitable now │
│ HIGH:      [count] — Likely path     │
│ MEDIUM:    [count] — Needs attention │
│ LOW:       [count] — Hardening       │
│ INFO:      [count] — Observations    │
└──────────────────────────────────────┘

────────────────────────────────────────
[CRITICAL] Finding Title
────────────────────────────────────────
Location:     file.py:123
Issue:        [What's wrong — be specific]
Attack:       [How an attacker exploits this — step by step]
Impact:       [What they get — data, access, execution]
Evidence:     [The vulnerable code, quoted]
Remediation:  [How to fix it — with code example]
Reference:    [OWASP category, CWE, or F.O.R.G.E. technique ID if applicable]

────────────────────────────────────────
[HIGH] Finding Title
────────────────────────────────────────
...

OWASP TOP 10 COVERAGE
[x] A01: Broken Access Control — [findings or "No issues found"]
[x] A02: Cryptographic Failures — [findings or "No issues found"]
[x] A03: Injection — [findings or "No issues found"]
[x] A04: Insecure Design — [findings or "No issues found"]
[x] A05: Security Misconfiguration — [findings or "No issues found"]
[x] A06: Vulnerable Components — [findings or "No issues found"]
[x] A07: Auth Failures — [findings or "No issues found"]
[x] A08: Data Integrity Failures — [findings or "No issues found"]
[x] A09: Logging Failures — [findings or "No issues found"]
[x] A10: SSRF — [findings or "No issues found"]

HARDENING RECOMMENDATIONS
Priority items that aren't vulnerabilities yet but would strengthen the posture:
□ [Recommendation 1]
□ [Recommendation 2]
□ [Recommendation 3]

VERDICT: [PASS / FAIL / CONDITIONAL]
- PASS: No CRITICAL or HIGH findings
- FAIL: Any CRITICAL finding, or 3+ HIGH findings
- CONDITIONAL: HIGH findings that have mitigating factors