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
- Passwords: argon2id or bcrypt (cost >= 10)
- JWT: 15-min access tokens, 7-day refresh tokens rotated on use
- Rate limiting: 5 attempts / 15 min on auth endpoints
- Sessions invalidated on password change
- OAuth state parameter validated, scoped API keys
- MFA enforced for admin accounts
- Password reset tokens are single-use and time-limited
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.