Threat Modeling

Purpose

Threat modeling identifies, for a specific system or feature, what’s worth protecting, who might attack it, and where trust boundaries lie — a deliberate exercise that surfaces security considerations a purely functional review tends to miss entirely.

The three questions

• Assets: what’s worth protecting — user data, session tokens, the integrity of the application itself, availability.
• Actors: who might attack it, and what are they capable of — an anonymous internet user, a malicious or compromised dependency, a user with a stolen session, an insider.
• Trust boundaries: where does data cross from a less-trusted context into a more-trusted one — a form submission, a parsed API response, a dependency’s install-time script, a file upload.

Behavior notes

• A threat model doesn’t need to be formal or exhaustive to be useful — a short “what’s the worst case here, and what would have to go wrong” exercise for a specific feature, done before shipping it, is often enough to surface a real gap.
• Trust boundaries are the most actionable output: they’re exactly the points where validation, sanitization, or capability restriction (recall capability-based design) actually needs to happen.
• Revisiting a threat model when a system’s actors or boundaries change (a new integration, a new user role) keeps it from going stale.

Common mistakes

• Treating threat modeling as a one-time, project-kickoff-only exercise rather than something revisited as a system evolves.
• Focusing only on external attackers, missing risk from a compromised dependency or an over-privileged internal component — both are legitimate “actors” in most real systems.

Runtime notes

A design and review practice, not a language or runtime feature — applies to any system regardless of its implementation technology.