Threat Modelling
debt(d9/e7/b7/t7)
Closest to 'silent in production until users hit it' (d9). The detection_hints field explicitly states 'automated: no' and the code_pattern is 'New features merged without security review or documented threat model' — there is no tooling to catch the absence of threat modelling. The gap only becomes visible when an attack surface is exploited in production, making this maximally invisible.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix suggests a per-feature lightweight approach, but the common_mistakes show the typical failure mode is never revisiting the threat model as the system evolves. Retrofitting threat modelling onto an existing system requires reviewing every feature, architectural component, and dependency across the codebase — a cross-cutting process that cannot be resolved with a localised fix.
Closest to 'strong gravitational pull' (e7). The applies_to contexts span web, api, and cli — the full breadth of the application. Because threat modelling is an architectural principle that must be revisited with every new feature and dependency change, it imposes a persistent, ongoing obligation on every developer and every change. The tags include 'architecture' and 'principles', signalling system-wide reach rather than localised scope.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The canonical misconception is explicit: developers treat threat modelling as a one-time pre-launch activity analogous to writing an initial design doc, when in reality it must be a living process revisited continuously. This mirrors how other 'upfront' activities (e.g., initial API design, database schema) are often treated as fixed after launch, making the wrong mental model highly intuitive and the correct one counterintuitive.
Also Known As
TL;DR
Explanation
Threat modelling (STRIDE, PASTA, LINDDUN) is a proactive security activity performed during design — typically cheaper than fixing vulnerabilities post-deployment. The process involves: identifying assets to protect, decomposing the application into data flows and trust boundaries, enumerating threats using a framework like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), and defining mitigations. Regular threat modelling sessions on new features integrate security into the development cycle rather than bolting it on.
Diagram
flowchart TD
SCOPE[Define Scope<br/>what are we protecting?] -->
ASSETS[Identify Assets<br/>user data, credentials, APIs] -->
THREATS[Identify Threats<br/>STRIDE analysis] -->
VULN[Find Vulnerabilities<br/>how could each threat succeed?] -->
MITIGATE[Design Mitigations<br/>controls for each threat] -->
VALIDATE[Validate<br/>test mitigations work]
subgraph STRIDE
S[Spoofing]
T[Tampering]
R[Repudiation]
I[Info Disclosure]
D[Denial of Service]
E[Elevation of Privilege]
end
style SCOPE fill:#1f6feb,color:#fff
style VALIDATE fill:#238636,color:#fff
Common Misconception
Why It Matters
Common Mistakes
- Threat modelling only once at project start and never revisiting as the system evolves.
- Identifying threats without assigning mitigations — a threat list with no actions provides no value.
- Focusing only on technical threats and missing business logic abuse scenarios.
- Not involving developers in threat modelling — security teams alone miss domain context.
Code Examples
// Feature built without threat modelling:
// New feature: users can export their data as CSV
// Shipped without asking: can users export OTHER users' data? (IDOR)
// Can the export be triggered to DoS the server? (resource exhaustion)
// Does the export include fields that should stay internal? (data exposure)
// All found in pentest 6 months later — expensive to fix# Threat modelling — STRIDE framework for PHP apps
# S — Spoofing (impersonation)
# Threats: credential stuffing, session theft
# Mitigations: MFA, SameSite cookies, session regeneration on login
# T — Tampering (data integrity)
# Threats: SQLi, XSS, request modification
# Mitigations: prepared statements, CSP, input validation
# R — Repudiation (deny actions)
# Threats: no audit trail
# Mitigations: immutable audit log with user, action, timestamp, IP
# I — Information Disclosure
# Threats: verbose errors, debug endpoints, IDOR
# Mitigations: display_errors=Off, auth on all endpoints
# D — Denial of Service
# Threats: rate limit bypass, ReDoS, large uploads
# Mitigations: rate limiting, regex review, upload size limits
# E — Elevation of Privilege
# Threats: mass assignment, broken access control
# Mitigations: fillable/guarded, policy-based authorisation