Threat Model: [system or feature]

Structured security review – find the abuse cases before the adversaries do. Adapted from the STRIDE methodology.

Field	Value
System / feature	[name]
Version	N.N
Owner	@name
Reviewers	@name, @name
Date	YYYY-MM-DD
Status	Draft / In review / Approved

Scope

• In scope: components, data flows, trust boundaries covered
• Out of scope: what this review deliberately excludes

System overview

flowchart LR
    U[User] --> LB[Load balancer]
    LB --> API[API service]
    API --> DB[(Database)]
    API --> EXT[Third-party API]

Trust boundaries (where data crosses a privilege level): public internet -> LB, service -> database, service -> third party.

Assets

Asset	Sensitivity	Why it matters
e.g. user credentials	High	Account takeover

Threats

Score each threat by STRIDE category. L = likelihood, I = impact (1-5), Risk = L x I.

ID	Threat	STRIDE	Component	L	I	Risk	Mitigation	Status
T-01	e.g. stolen session token replayed	Spoofing	Auth	3	5	15	Short TTL + rotation	Open
T-02

STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.

Assumptions & dependencies

What is relied on without verification: TLS configuration, third-party SLAs, managed-service security, upstream patching.

Unmitigated risks & acceptance

Threat	Residual risk	Accepted by	Date	Expiry
		@name	YYYY-MM-DD	YYYY-MM-DD

Follow-ups

• File tickets for every Open mitigation
• Re-run this model after [trigger: major change / N months]