Skip to content
sec/atlas
back to the map
practice
stage: source
3 min read

Threat modeling: think like the attacker before coding

Threat modeling is the structured conversation that discovers what can go wrong while it is still cheap to fix: in the design, not in the pentest.

STRIDEOWASP Threat DragonMicrosoft Threat Modeling ToolpytmIriusRisk

What it is

Threat modeling is the exercise of looking at a system (or a feature) and systematically asking what can go wrong, who could cause it and what we do about it. It happens before or during design, when changing a decision costs a conversation and not an entire sprint.

, and find defects that already exist in the code or the environment. The finds design defects: the service that trusts a header the client controls, the password reset flow that leaks whether the email exists, the bucket that mixes tenants' data. No scanner sees these because no line of code is "wrong".

The four questions

The simplest method fits in four questions, repeated at every relevant architecture change:

  • What are we working on? A (DFD) with actors, processes, data stores and trust boundaries.
  • What can go wrong? Walk through each element and each flow that crosses a looking for threats ( helps here).
  • What are we going to do about it? For each threat: mitigate, eliminate, transfer or accept, with an owner and a recorded decision.
  • Did we do a good job? Review the model after the release and after each incident, because the system changes and the model ages.

STRIDE: a threat checklist

STRIDE is a Microsoft mnemonic that maps each letter to a violated security property. When looking at a flow in the diagram, you ask whether each of the six categories applies:

  • Spoofing (identity forgery) violates authenticity: someone impersonates another user or service.
  • Tampering violates integrity: data or code altered in transit or at rest.
  • Repudiation violates non-repudiation: there is no log to prove who did what.
  • Information disclosure violates confidentiality: data exposed to those who should not see it.
  • Denial of service violates availability: the service is exhausted or taken down.
  • Elevation of privilege violates authorization: a regular user starts acting as an admin.

Threat model as code

The model does not need to live in a forgotten slide. Tools like pytm describe the system in code, generate the DFD and list the applicable threats. Versioned alongside the repository, the model goes through code review and changes in the same PR that changes the architecture.

tm.py - example with pytmpython
from pytm import TM, Server, Datastore, Dataflow, Boundary, Actor

tm = TM("Checkout API")
internet = Boundary("Internet")
vpc = Boundary("Private VPC")

user = Actor("Customer", inBoundary=internet)
api = Server("Checkout API", inBoundary=vpc)
db = Datastore("Orders", inBoundary=vpc, isEncrypted=True)

Dataflow(user, api, "POST /checkout (HTTPS)", isEncrypted=True)
Dataflow(api, db, "INSERT order")

tm.process()  # generates the DFD and the STRIDE threat list

How to fit it into the pipeline

The most practical trigger is the same as for code review: a new feature that touches authentication, sensitive data, an external service or a trust boundary calls for half an hour of threat modeling before the first commit. For everything else, a quick threat review in the PR template is enough.

Threats become traceable items: each mitigation points to a test, a SAST rule or a pipeline gate. That way the threat model stops being a document and starts generating checks that run on their own, and the map closes the loop: the design informs what SAST, DAST and the gates need to check.

SASTStatic analysis: examines the code without running it. It finds issues through flow analysis, not guesswork.see in glossary →DASTDynamic testing: attacks the running application from the outside, as a black box.see in glossary →SCAComposition analysis: inventories third-party dependencies and cross-references them with known CVEs.see in glossary →Threat modelA structured answer to four questions: what are we building, what can go wrong, what will we do about it, and did we do a good job.see in glossary →DFDdata flow diagramA drawing of a system's actors, processes, data stores and flows, with trust boundaries marked. It is the input to threat modeling: threats appear where a flow crosses a boundary.see in glossary →Trust boundarytrust boundaryA line where the trust level of the data or of whoever sends it changes (internet to VPC, service to database, user to admin). Everything that crosses it must be authenticated, authorized and validated.see in glossary →STRIDEA mnemonic of six threat categories (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) used as a checklist when walking through a data flow diagram.see in glossary →

connections on the map

  • Shift-leftstarts at designThreat modeling: think like the attacker before coding
  • Threat modeling: think like the attacker before codingdefines what to testSAST
  • Threat modeling: think like the attacker before codingbecomes a gateDevSecOps

updated on 14/10/2026 · sources to go deeper · report an error

in other domains

Study before

test what you learned

Loading questions…