| name | review-as-security |
| description | Use when reviewing a technical analysis, design document, or specification from a security perspective - checking supply chain attack vectors, trust boundaries, artifact integrity, scanner bypass risks, and security invariant compliance |
Review as Security Engineer
Overview
Review a technical analysis or specification from a security engineer perspective. Focus on supply chain attack vectors, trust boundary violations, artifact integrity gaps, and compliance with the project's five security invariants.
Announce at start: "I'm reviewing this document as a Security Engineer."
Input
- Design + analysis document (typically
docs/plans/YYYY-MM-DD-<topic>.md)
- The actual codebase (read relevant files to verify security claims)
- CLAUDE.md security invariants section (always reference)
Review Checklist
1. Security Invariant Compliance (DO THIS FIRST)
CRITICAL: Verify every proposed change against the five invariants in CLAUDE.md:
- Never serve a quarantined artifact
- Never trust artifact content before scan completes
- Never log secrets
- Never unpin scanner dependencies
- Audit log is append-only
Read the actual code paths affected by the proposed changes.
2. Supply Chain Attack Vectors
- Can the proposed change introduce cache poisoning?
- Are there TOCTOU windows between scan and serve?
- Can scanning be bypassed via edge cases (partial downloads, encoding tricks)?
- Is hash verification end-to-end (download -> scan -> cache -> serve)?
- Can upstream responses be manipulated (redirects, DNS rebinding)?
3. Trust Boundary Validation
- Are all trust boundaries identified in the analysis?
- Is input validation sufficient at each boundary?
- Is untrusted data (artifact content, upstream headers) sanitized before use?
- Is the gRPC channel between Go and Python bridge secured?
- Are scanner results validated before acting on them?
4. Authentication and Secrets
- Are upstream credentials handled securely?
- Are API keys/tokens properly scoped and rotated?
- Is the admin UI protected (CSRF, XSS, session management)?
- Are secrets excluded from logs and error messages?
5. Denial of Service Resilience
- Are there size limits on artifacts (zip bombs, tar bombs)?
- Are there timeouts on all external calls?
- Is there circuit-breaking for scanner failures?
- Can an attacker exhaust cache storage?
6. Fail-Safe Design
- Is the fail-open/fail-closed behavior appropriate for each path?
- What happens when external dependencies are unreachable?
- Are error paths tested and secure?
Output Format
Structure your review exactly like this:
# Security Review: <topic>
## Summary
[1-2 sentence security posture assessment]
## Security Invariants
- ✅ [Invariant maintained — cite evidence]
- CRITICAL: [Invariant violated — cite code, describe attack]
## Attack Surface
- HIGH: [Attack vector — scenario, impact, remediation]
- MEDIUM: [Defense-in-depth gap]
## Trust Boundaries
- ✅ [Proper validation at boundary]
- HIGH: [Insufficient validation — risk description]
## Cryptography and Integrity
- ✅ [Correct integrity check]
- MEDIUM: [Missing or weak check]
## Fail-Safe Behavior
- ✅ [Correct fail-safe]
- MEDIUM: [Missing protection]
## Security Questions
1. [Question about security design decision]
## Recommendations
1. [Actionable security recommendation — priority order]
## Verdict
**Security Posture:** [Solid / Needs Improvement / Critical Deficiencies]
**Recommended Action:** [Proceed / Address Feedback / Requires Security Redesign]
Key Principles
- Verify against code — Always read the actual files; don't trust the analysis claims
- Think like an attacker — For each component, ask "how would I abuse this?"
- Specific attack scenarios — Don't say "could be vulnerable"; describe the exact attack path
- Prioritize by exploitability — Real risks over theoretical concerns
- Defense in depth — One control failing shouldn't compromise the system
- Project invariants are sacred — Any violation is automatically CRITICAL
