Threat modeling has a reputation for being heavyweight — a process owned by a dedicated security team, producing documents that nobody reads. It does not have to be that way. At its core, threat modeling is a structured conversation, and a small team can get most of the value in a single afternoon.

The four questions

Every useful threat model answers four questions, in order:

What are we building?
What can go wrong?
What are we going to do about it?
Did we do a good job?

The first question is the one teams skip, and skipping it is why the others fail. You cannot reason about what can go wrong with a system you have not described.

You will find more issues in an hour of conversation than in a week of automated scanning.

Start with a drawing

Before you write a single threat, draw the system. Boxes for components, arrows for data, and — most importantly — lines for trust boundaries: the places where data crosses from something you control into something you do not, or vice versa.

# Sketch the data flow before you enumerate the threats
echo "browser -> api gateway -> service -> database" > model.txt
echo "  trust boundary: browser/gateway (untrusted input)" >> model.txt
echo "  trust boundary: service/database (sensitive data)" >> model.txt

Walk the boundaries

With the diagram in hand, walk each trust boundary and ask what an attacker on the untrusted side could do. Tampering with requests? Replaying them? Reading data they should not see? You do not need a formal taxonomy to be productive, though frameworks like STRIDE can help jog your thinking when the conversation stalls.

The output does not need to be a polished document. A list of risks, each with an owner and a decision — fix, accept, or investigate — is enough. The point is not the artifact. The point is that you looked.