| name | security-review-checklist |
| description | Use when performing security review, threat modeling, or OWASP-aligned analysis on code changes. |
Purpose
Provides a systematic security review framework covering threat modeling, OWASP-aligned analysis, and vulnerability assessment for code changes.
When to Use
Use this skill during security review to ensure systematic coverage of security concerns.
Review Order
- Attack surface — What data enters, exits, or crosses trust boundaries?
- Input validation — Are all inputs validated and sanitized?
- Authentication and authorization — Are access controls correct?
- Data protection — Is sensitive data handled securely?
- Dependencies — Are third-party libraries safe?
- Configuration — Are security settings correct?
Threat Model (Lightweight)
For each change, identify:
- Data flow: What data enters the system, where does it go, and who can access it?
- Trust boundaries: Where does trusted code interact with untrusted input?
- Assets at risk: What could an attacker gain access to if this code is vulnerable?
- Threat actors: Who might exploit this? (external user, internal user, automated bot)
OWASP Top 10 Quick Check
| Category | Check | Applies? |
|---|
| A01: Broken Access Control | Are authorization checks present and correct? | |
| A02: Cryptographic Failures | Is sensitive data encrypted properly? | |
| A03: Injection | Are queries parameterized? Is user input sanitized? | |
| A04: Insecure Design | Does the design have security controls built in? | |
| A05: Security Misconfiguration | Are defaults secure? Are unnecessary features disabled? | |
| A06: Vulnerable Components | Are dependencies up to date and free of known CVEs? | |
| A07: Authentication Failures | Are auth mechanisms robust (rate limiting, MFA)? | |
| A08: Data Integrity Failures | Is deserialization controlled? Are updates verified? | |
| A09: Logging Failures | Are security events logged without exposing secrets? | |
| A10: SSRF | Are outbound requests validated against allowlists? | |
Finding Format
For each finding:
### [Severity]: [Title]
**OWASP**: [Category, e.g., A03: Injection]
**Location**: [file:line]
**Description**: [What the vulnerability is]
**Impact**: [What could happen if exploited]
**Fix**: [Suggested remediation approach]
Severity levels:
- Critical — Exploitable now, high impact, fix before merge
- High — Likely exploitable, significant impact, fix before merge
- Medium — Exploitable under specific conditions, fix soon
- Low — Minor risk or defense-in-depth improvement
Output Format
Follow the structured report format defined in the Security agent:
- Summary — what was reviewed, overall security posture assessment
- Threat Model table — data flows, trust boundaries, assets at risk, and threat actors
- Spec Security Coverage table — each security requirement mapped to Met / Unmet / Partial
- Metrics — attack surfaces reviewed, dependencies changed, CVEs found
- Findings table — severity-rated (🔴🟠🟡🔵), OWASP category, file:line, vulnerability, impact, and suggested fix
- Dependency Risks table — packages, versions, CVEs, and recommended actions
- Recommended Actions — checkboxes separating must-fix from advisory
- Risk Level — Low / Medium / High / Critical with one-line justification
Checklist
