Threat Modeling for Engineers: A Practical Guide

Threat modeling is one of those terms that gets thrown around a lot in security discussions but is rarely understood beyond buzzword level. A recent blog post by Soatok cuts through the noise with a straightforward, engineer-friendly introduction to the practice. While the original post is aimed at a general technical audience, the core lessons are directly applicable to anyone building software systems — especially in infrastructure, microservices, and distributed applications.

What a Threat Model Actually Needs to Answer

At its simplest, a threat model should answer seven questions. The first four are the basics: what are we protecting, who or what wants to harm it, how might they attack, and what will we do to prevent it. But the real value comes from the next three: how are the assets connected (think in graphs, not lists), what assumptions are we making, and what threats are we deliberately not addressing.

Too many teams skip the assumptions step. If your model assumes only one valid key per message (like AES-GCM or ChaCha20-Poly1305), but your system introduces multiple valid keys — say, through abuse reporting — you've just invalidated your own security guarantees. The Invisible Salamanders attack is a perfect example of this mismatch.

How to Build a Threat Model

Start by mapping out your system's components on paper or a whiteboard. Draw every relationship: which services talk to each other, what depends on what. Then draw a box around the whole thing and iteratively zoom in on each component. For each iteration, note inputs and outputs, and answer the seven questions as best you can. Repeat until you've drilled down as far as your abstraction allows.

This top-down approach surfaces inappropriate relationships — like a database that shouldn't have an RSS feed, or a load balancer that doesn't need to know about X25519 key exchange.

What a Good Threat Model Looks Like

A well-structured threat model documents assumptions up front, then lists assets, actors, and risks. Risks should be categorized: prevented by design, mitigated (interesting for researchers), addressable (requires operator care), or open (risks you accept). Being honest about open risks is critical — you cannot address every possible attack.

The Matrix protocol's threat model is a cautionary example. It fails to clearly separate assumptions from mitigations, making it hard to reason about where the security boundaries actually lie.

Key Takeaways for Engineers

• Threat models are living documents, not one-time artifacts. Update them as your system evolves.
• Always state your assumptions explicitly. Wrong assumptions break the entire model.
• Map relationships as graphs, not lists — attackers think in graphs.
• Document what you're not protecting against. Honesty about blind spots is better than false confidence.