| name | security-review |
| description | When the user needs a security assessment — threat modeling, vulnerability review, auth flow audit, dependency scanning, or says "is this secure", "review for vulnerabilities", "threat model", "security audit", "pen test prep". |
| related | ["code-review","architecture-design","soc2-prep"] |
| reads | ["startup-context"] |
Security Review
When to Use
- The user wants a security audit of their application, infrastructure, or specific feature
- They need a threat model before launching or a penetration test preparation review
- They have a dependency vulnerability alert and need remediation guidance
- They are handling sensitive data (PII, payment, health) and need verification
- Code audit, secrets detection, or compliance assessment is requested
Context Required
From startup-context: tech stack, deployment environment, compliance requirements, data types. Also ask:
- Scope — Full app, feature, auth system, single PR, infrastructure, or cloud environment
- Data types — PII, payment, health, credentials, or other sensitive data handled
- Compliance requirements — SOC 2, HIPAA, PCI-DSS, GDPR, ISO 27001
- Authorization — Confirm written authorization exists before any active testing
Workflow
Follow a five-phase methodology. Automated scanning precedes manual review. Authorization verification is mandatory before active testing.
- Scope definition — Establish attack surface boundaries. Identify all components, data flows, and trust boundaries. Confirm authorization. Define in-scope and out-of-scope.
- Automated scanning — Execute tooling before manual review:
- SAST:
semgrep --config=auto across the codebase
- Dependency audit:
npm audit / pip-audit / govulncheck / trivy fs .
- Secrets detection: Scan for hardcoded credentials, API keys, tokens in source
- Container scanning:
trivy image for containerized deployments
- Record all automated findings for validation in the next phase.
- Manual code review — Conduct contextual analysis that automated tools miss:
- Authentication and authorization flow tracing end-to-end
- Business logic vulnerabilities (price manipulation, race conditions, privilege escalation)
- Data flow analysis for sensitive information (where does PII enter, transit, and persist?)
- STRIDE threat modeling against each component and data flow
- Validation and classification — Test findings and assign severity:
- Validate automated findings to eliminate false positives
- Assign CVSS v3.1 scores; assess exploitability in context
- Classify by business impact, not just technical severity
- Reporting — Document vulnerabilities with precise locations, business impact, and corrective actions. Deliver a prioritized remediation roadmap.
Output Format
# Security Review: [Scope Description]
## Executive Summary
Overall risk posture (Critical / High / Medium / Low), top findings count, and business impact summary.
## Threat Model (STRIDE)
| Threat | Category | Asset | Impact | Likelihood | Risk |
## Findings
### Critical / High / Medium / Low
- **[SEC-N] Title** — CVSS X.X — file:line — description, business impact, remediation with code example
## Auth Flow Assessment
End-to-end trace of authentication and authorization with findings.
## Dependency Vulnerabilities
| Package | Current Version | CVSS | Fix Version | Exploitable in Context? |
## Remediation Roadmap
Prioritized action list with timelines.
Frameworks & Best Practices
STRIDE Threat Modeling
Apply to every component and data flow:
- Spoofing — Can attackers forge tokens or impersonate users? Are API keys rotatable?
- Tampering — Can requests be modified in transit? Are webhooks signed? Is data integrity verified?
- Repudiation — Are critical actions logged? Are logs tamper-evident?
- Information Disclosure — Stack traces in error responses? PII encrypted at rest and in transit?
- Denial of Service — Rate limits in place? Can one user exhaust resources for all?
- Elevation of Privilege — Can regular users access admin functions? Are role checks server-side?
OWASP Top 10 Checks
- Injection — Parameterize SQL/NoSQL; check OS commands, SSTI, LDAP
- Broken Auth — argon2id/bcrypt, session timeout, rate limiting on login
- Data Exposure — TLS 1.2+, PII encrypted at rest, HSTS headers
- XXE — Disable DTD processing, prefer JSON over XML
- Access Control — Server-side authz on every endpoint, no IDOR, CORS whitelist
- Misconfig — Debug mode off, default credentials removed, security headers present
- XSS — Output encoding, Content Security Policy, HTTP-only cookies
- Deserialization — Validate schema, prefer JSON, reject untrusted serialized objects
- Vulnerable Deps —
npm audit, pip-audit, trivy, govulncheck
- Logging — Auth events, admin actions, access violations logged with alerts
CVSS v3.1 Scoring Guide
- Critical (9.0-10.0): RCE, auth bypass, full data breach, complete system compromise
- High (7.0-8.9): Privilege escalation, significant data exposure, SSRF to internal services
- Medium (4.0-6.9): Stored XSS, CSRF, limited IDOR, information disclosure
- Low (0.1-3.9): Missing security headers, minor info disclosure, verbose errors
Auth Flow Checklist
Scanning Tools
- SAST:
semgrep --config=auto (all stacks), bandit (Python), gosec (Go), eslint-plugin-security (Node)
- Dependencies:
npm audit / pip-audit / govulncheck / trivy fs .
- Containers:
trivy image
Mandatory Constraints
- Never test production without explicit written authorization
- Never exploit beyond proof-of-concept demonstration
- Always sequence automated scanning before manual review
Remediation Priority
- Actively exploitable + critical data — immediately
- Auth/authz bypass — 24 hours
- Injection — 48 hours
- Data exposure / critical CVEs — 1 week
- Config hardening — 2 weeks
- Defense-in-depth — next sprint
Related Skills
code-review — chain when findings require code-level fixes and reviewarchitecture-design — chain when findings reveal architectural security flawssoc2-prep — chain when review is part of compliance preparation
Examples
Example prompt: "Review the security of our user authentication system. We use JWT with Express."
Good output snippet:
# Security Review: JWT Authentication System
## Executive Summary
Risk posture: **Critical**. Hardcoded JWT secret and non-expiring tokens.
## Findings
### Critical (CVSS 9.8)
- **[SEC-1] Hardcoded JWT secret** — auth/config.js:3 — Secret is
"supersecret123". Attacker can forge any token.
**Fix:** Move to env var, generate with `openssl rand -base64 64`.
### Critical (CVSS 9.1)
- **[SEC-2] Tokens never expire** — auth/jwt.js:12 — No `expiresIn`.
**Fix:** Set `expiresIn: '15m'`, implement refresh token rotation.
