Why design is the cheapest place for a mistake
The cost of fixing a security gap grows with every stage it goes unnoticed. A mistake in the architecture design is a change on a diagram. The same mistake found by a pentester two weeks before a contract is signed is a redesign of a working system, retests and a pushed-back deadline.
Most security tools work on finished code — scanners find what has already been written. Threat modeling works earlier: it asks about problems before the first line of code exists. That’s why it’s one of the most cost-effective practices in the entire delivery process.
What threat modeling is
Threat modeling is a structured conversation about what could go wrong in the system being designed and what we’ll do about it. It isn’t an audit or a scan. It’s a way of looking at the architecture through the eyes of someone who’d want to attack it.
In practice it comes down to four questions:
- What are we building? (a diagram of the system and data flows)
- What could go wrong? (threats)
- What do we do about it? (controls)
- Did we do it well? (verification)
The first question sounds trivial, but it’s the source of most of the value. A team that draws its own system and data flows regularly discovers trust boundaries and paths no one had consciously thought about before.
STRIDE — six categories you get asked about
STRIDE is the most commonly used method for categorizing threats. The name is an acronym for six types:
- Spoofing — impersonating someone or something. Can we confirm the other party is who they claim to be?
- Tampering — unauthorized modification of data or code. Are data in transit and at rest protected against change?
- Repudiation — denying an action. Do we have a trail of who did what?
- Information disclosure — a leak of information. Does data reach only those entitled to it?
- Denial of service — a refusal to operate. Can the system be overloaded or blocked?
- Elevation of privilege — gaining higher privileges. Can someone do more than they should be able to?
STRIDE doesn’t give answers — it gives a structure of questions. Going category by category through each element of the diagram, the team systematically checks areas that are easy to skip in an unstructured discussion.
The value of STRIDE isn’t in finding exotic attacks. It’s that you can’t “forget” about something — every trust boundary goes through the same set of questions.
What it looks like in practice
The starting point is a data flow diagram of the real system, not a textbook example. On it you mark the elements (services, data stores, external processes) and the trust boundaries — the places where data crosses between areas with different levels of trust.
Then, going through the boundaries and flows, the team asks the STRIDE questions. Each threat found is recorded together with a decision: mitigate, accept the risk, or transfer it elsewhere. The result isn’t a report for a drawer, but a list of concrete things to do wired into the team’s backlog.
Good threat modeling is a conversation between engineers, not a presentation by an expert. A team that has been through the process itself can repeat it next time without outside help.
The most common mistake: a one-off workshop
The most common way threat modeling stops working is treating it as a one-off event. The team runs a workshop, a diagram is produced, a quarter later the system has changed, and the diagram sits on a drive with no one going back to it.
Threats change together with the system. A new integration, a new data store, a new authentication path — each of them changes the picture. Modeling that doesn’t keep up with changes describes, after a few months, a system that no longer exists.
Wiring it into the delivery process
That’s why threat modeling makes sense as an element of the process, not as a separate project. In practice this means a few things:
- lightweight modeling on every significant architecture change, not just once at the start,
- a diagram kept close to the code, versioned alongside it,
- people on the team who can run modeling on their own — with no bottleneck in the form of a single expert.
Built this way, threat modeling stops being a cost and becomes the way the team designs. It’s the same principle that runs through the whole secure delivery process: security built into the way you work works; bolted on after the fact — it doesn’t.