Security Threat Model
Purpose
Use this skill before implementing or approving security-sensitive changes. It complements auth-security and server-security by mapping assets, attackers, trust boundaries, and concrete controls.
Scope First
Identify:
- Assets: credentials, tokens, user data, tenant data, money movement, admin actions.
- Actors: anonymous user, authenticated user, tenant admin, internal operator, compromised dependency.
- Trust boundaries: browser/server, service/service, tenant/tenant, CI/runtime, third-party callbacks.
- Entry points: API routes, CLI commands, jobs, webhooks, uploads, config files.
- Existing controls: validation, authz, rate limits, audit logs, secret storage.
Threat Checklist
Check at least:
- Spoofing: can an identity, tenant, callback, or service be forged?
- Tampering: can payloads, configs, migrations, artifacts, or logs be altered?
- Repudiation: is there an audit trail for sensitive actions?
- Information disclosure: can secrets, PII, logs, or tenant data leak?
- Denial of service: can expensive paths be amplified?
- Elevation of privilege: can user or service permissions expand?
- Supply chain: can dependencies, scripts, CI, or generated files introduce risk?
Required Controls
Every finding needs one of:
- preventive control in production code,
- detective control with alerting,
- compensating manual control with owner and expiry,
- explicit accepted risk with rationale.
Do not accept "warn and continue" for authz, secrets, tenant isolation, injection, or payment/security-critical failures.
Output Shape
scope:
assets:
trust_boundaries:
entry_points:
threats:
required_controls:
tests_or_probes:
residual_risks:
review_gate:
For implementation work, include exact files and verification commands that prove the controls are active.