When to Use
- A security review request lacks context about the threat model
- The scope of an audit or assessment is ambiguous
- Assumptions about trust boundaries need validation
- The deployment environment or architecture is unclear
- Risk tolerance or compliance requirements are not stated
When NOT to Use
- Context is already sufficient to proceed with analysis
- The task is purely mechanical (run a scan, parse output)
- Questions would block urgent incident response
Key Questions to Ask
Before Any Security Review
- What is the threat model? Who are the adversaries?
- What are the trust boundaries? What input is untrusted?
- What is the deployment environment (cloud, on-prem, edge)?
- What compliance requirements apply (PCI, HIPAA, SOC2)?
- What is the risk tolerance? (startup MVP vs. banking app)
Before Code Audit
- What changed recently? What is the scope of review?
- Are there known vulnerabilities or areas of concern?
- What authentication/authorization model is used?
- What sensitive data does the application handle?
- Has there been a previous audit? What was found?
Before Architecture Review
- What are the data flow paths for sensitive information?
- Where are secrets stored and how are they rotated?
- What is the blast radius if a single component is compromised?
- What monitoring and alerting is in place?
Why This Matters
Security analysis with wrong assumptions is worse than no analysis — it creates false confidence. A SQL injection review is useless if the real risk is an exposed admin panel. Asking the right questions up front ensures effort is directed at actual risks.
Anti-Patterns to Avoid
| Anti-Pattern | Problem |
|---|---|
| Assuming scope | Missing critical attack surface |
| Skipping threat model | Defending against wrong adversary |
| Not asking about data sensitivity | Misjudging impact severity |
| Assuming deployment environment | Missing environment-specific risks |
| Not clarifying "secure enough" | Over- or under-engineering defenses |