Threat modelling before the first line of code

Almost every breach we are called in to investigate traces back to a decision made in a design meeting, not a typo in a function. Someone decided that the invoice ID would be sequential. Someone decided the internal admin API did not need authentication because it was “only reachable from the VPN”. Nobody wrote those decisions down as risks, so nobody revisited them.

Threat modelling is the discipline of writing them down. It costs about two hours at the start of a project and it is the highest-return security activity we know of.

The session we actually run

We block two hours with the people who understand the system — usually a tech lead, a product owner and one of our security engineers. No tooling, no template gymnastics. Four questions, in order.

1. What are we building?

Someone draws the system on a whiteboard. Boxes for components, arrows for data flows, and a line around anything that constitutes a trust boundary — the browser, the public API edge, the third-party payment processor, the internal network. If the group cannot agree on where the trust boundaries are, that disagreement is itself the first finding.

2. What can go wrong?

We walk each data flow using STRIDE as a prompt, not a religion: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. For each arrow crossing a trust boundary we ask the six questions out loud. Most produce nothing. The ones that produce an uncomfortable pause are the interesting ones.

The single most productive prompt we have found is simpler than STRIDE: “what happens if the person on the other end of this arrow is hostile and patient?”

3. What are we going to do about it?

Every identified threat gets one of four outcomes, decided in the room: mitigate, transfer, accept, or eliminate. Accepting a risk is a legitimate answer — as long as it is written down with a name against it. Undocumented acceptance is how organisations end up surprised by their own decisions two years later.

4. Did we do a good enough job?

We book a thirty-minute review after the first architecture spike. Designs move; the model has to move with them. A threat model that is only produced once is a compliance artefact, not a security control.

What comes out of the room

One page. A diagram, a table of threats with their decided outcome, and a short list of engineering tasks that go straight into the backlog with the same priority as any other work. If the output needs a document template, the session was too formal.

The point of a threat model is not the document. It is that four people now share the same mental picture of how the system fails.

The findings that recur

Across the last three years of running these sessions, the same four issues surface more than any others:

• Object references that are guessable. Sequential IDs on any resource that belongs to a user. This is the root of most IDOR findings we report.
• Authorisation checked at the route, not the record. The endpoint verifies you are logged in; it never verifies the row belongs to you.
• Internal services trusted by network position. “It is behind the firewall” stops being true the moment any single service is compromised.
• Secrets with no rotation story. Not that they are stored badly — that nobody knows how to change them without downtime, so they never do.

None of these are exotic. All four are far cheaper to prevent in a design session than to remediate after a pentest, and dramatically cheaper than after an incident.

Start smaller than you think

If two hours is a hard sell, run twenty minutes on one feature. Take the next thing you are about to build, draw it, and ask the hostile-and-patient question of every arrow that crosses a boundary. You will find something. You always do.