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.
1---2name: security-threat-model-53description: Threat-model product features, APIs, data flows, secrets, permissions, supply-chain changes, auth boundaries, and risky code paths before or during implementation. Use when touching authentication, authorization, payments, secrets, user data, uploads, webhooks, admin tools, innerHTML/eval/exec, dependency upgrades, or cross-tenant access.4---5
6# Security Threat Model
7
8## Purpose
9
10Use 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.
11
12## Scope First
13
14Identify:
15
161. Assets: credentials, tokens, user data, tenant data, money movement, admin actions.
172. Actors: anonymous user, authenticated user, tenant admin, internal operator, compromised dependency.
183. Trust boundaries: browser/server, service/service, tenant/tenant, CI/runtime, third-party callbacks.
194. Entry points: API routes, CLI commands, jobs, webhooks, uploads, config files.
205. Existing controls: validation, authz, rate limits, audit logs, secret storage.
21
22## Threat Checklist
23
24Check at least:
25
26- Spoofing: can an identity, tenant, callback, or service be forged?
27- Tampering: can payloads, configs, migrations, artifacts, or logs be altered?
28- Repudiation: is there an audit trail for sensitive actions?
29- Information disclosure: can secrets, PII, logs, or tenant data leak?
30- Denial of service: can expensive paths be amplified?
31- Elevation of privilege: can user or service permissions expand?
32- Supply chain: can dependencies, scripts, CI, or generated files introduce risk?
33
34## Required Controls
35
36Every finding needs one of:
37
38- preventive control in production code,
39- detective control with alerting,
40- compensating manual control with owner and expiry,
41- explicit accepted risk with rationale.
42
43Do not accept "warn and continue" for authz, secrets, tenant isolation, injection, or payment/security-critical failures.
44
45## Output Shape
46
47```text
48scope:
49assets:
50trust_boundaries:
51entry_points:
52threats:
53required_controls:
54tests_or_probes:
55residual_risks:
56review_gate:
57```
58
59For implementation work, include exact files and verification commands that prove the controls are active.