Threat modeling sounds like something only banks and defense contractors do — a heavyweight process with specialized tools and a dedicated security team. It is not. At its core, threat modeling is a structured conversation about what could go wrong, and a small team can get most of the value in an afternoon. Here is a practical method you can actually run.
Four Questions Are the Whole Method
Strip away the frameworks and threat modeling comes down to four questions, asked in order:
- What are we building? Draw the system — components, data stores, and the flows between them. A whiteboard diagram is enough.
- What can go wrong? Walk each flow and boundary and brainstorm abuse. This is the heart of it.
- What are we going to do about it? For each real threat, decide: mitigate, accept, or design it out.
- Did we do a good job? Review the model when the design changes, and check that the mitigations actually shipped.
That’s it. Everything else is refinement of these four questions.
Draw the Data Flow and Find the Boundaries
The single most useful artifact is a simple data-flow diagram: boxes for components, cylinders for data, arrows for flows. Then draw the trust boundaries — the lines where data crosses from something you control to something you don’t, or from less-trusted to more-trusted. The internet meeting your API. A third-party service. User input entering your logic. Almost every serious vulnerability lives on a trust boundary, so marking them tells you exactly where to look.
Use STRIDE as a Prompt, Not a Bureaucracy
To brainstorm “what can go wrong,” a checklist helps you not miss categories. STRIDE is a common one — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. For each trust boundary, ask whether each applies: Could someone pretend to be another user here? Tamper with this data in transit? Read something they shouldn’t? Do more than they’re allowed? Use it as a memory aid to spark the conversation, not as paperwork to fill out. The goal is finding real threats, not completing a template.
Write Down the Decisions
For each threat worth acting on, record what you decided and why — the mitigation, or the conscious choice to accept the risk. This record is quietly valuable: it stops the same debate recurring, it shows an auditor you thought about security deliberately, and it means the next person to touch the system inherits your reasoning instead of guessing. A threat model is a living document, not a one-time ceremony — revisit it when the architecture changes.
Start Small, Start Now
You do not need a tool or a certification to begin. Take your riskiest feature, draw it, mark the boundaries, run the four questions with your team, and write down what you find. You will surface issues worth fixing on the first try — almost everyone does.
BulletproofSoft runs threat modeling as part of secure development — facilitating the session, drawing out the threats your team is closest to, and turning them into concrete design decisions. Tell us what you’re building and we will model it with you.
Pick a Scope You Can Finish in One Sitting
The four questions work at any size, but the conversation degrades when the scope is open ended. Pick one service, one feature, or one data path, and draw everything outside it as a labeled box with an arrow into your diagram. A model that covers a checkout flow completely is worth more than a model that covers the whole product at the depth of a slide, and coverage accumulates: the stubbed boxes you drew this time become the subject of the next session, so a system gets modeled a piece at a time rather than all at once.
Scope problems announce themselves as friction rather than as a decision, and they show up in the first twenty minutes. Signs the scope is too big:
- The diagram is still being drawn halfway through the session.
- Two people are debating a component that neither of them deploys.
- The same threat keeps reappearing at a different layer, so nobody can tell whether it was already handled.
- Nobody in the room can say where untrusted input first enters the part under discussion.
- The list of external services is longer than the list of your own components.
What the Two STRIDE Variants Cost
STRIDE has two documented variants and they behave differently in a room. STRIDE-per-element pairs each element type on the diagram with the categories usually considered applicable to it (external entities with spoofing and repudiation, data flows with tampering, information disclosure and denial of service, processes with all six) and works through the resulting grid. STRIDE-per-interaction takes a source, a destination and the flow between them as one unit and asks about that. The per-element grid is what gave STRIDE its paperwork reputation: on a diagram with twenty elements it produces a fixed number of cells to fill whether or not anything interesting lives in them, and the cells fill fastest with threats that are technically in the category and irrelevant in practice. If you want a coverage check once the boundary conversation is finished, the element table is one way to notice a category that never came up at all, but that is a spot check on your notes, not a second pass over the diagram.
STRIDE also has blind spots worth naming out loud, because no category prompts for them. Business logic abuse is the big one: a valid user, correctly authenticated and correctly authorized, performing legitimate operations in an order or a quantity you did not intend. Race conditions are the same problem in miniature, so it is worth asking explicitly what happens when two of these requests arrive at once. For privacy work, LINDDUN (linkability, identifiability, non-repudiation, detectability, disclosure of information, unawareness, non-compliance) is the checklist aimed at what a working system reveals rather than at what an attacker breaks, and it is the one to reach for when the system handles personal data.
Turning the List into Decisions
Acceptance is the decision that goes wrong most often, because it is the one that leaves no trace in the code. An accepted risk with no owner and no stated assumption is an unfixed bug with a paper trail: nobody can tell later whether the risk was weighed or waved through. Record who accepted it, the assumption it rests on (the endpoint is not reachable from outside the VPC, the data is public anyway, the blast radius is one test account), and the condition that would reopen it. Acceptance belongs to whoever can carry the consequence, not to whoever happened to be in the room.
Before arguing about priority, establish reachability, because most disagreements about severity are actually disagreements about who can reach the code path. These questions do the sorting:
- Can an unauthenticated caller reach this path, or does it require a valid session?
- Does exploitation require credentials the attacker would have to steal first, and from where?
- Can it be automated across accounts, or does each attempt need a human?
- What does the attacker hold afterward: one user's data, one tenant's data, or the signing key?
- Would anything in the logs show that it happened?
Make the Fourth Question Checkable
Checking that the mitigations actually shipped works only if each mitigation landed on something with a name. Give every threat you act on an identifier, then attach it to a test case, a CI check, a configuration assertion, or a written design decision, and reference that identifier in the commit or pull request that implements it. The fourth question then becomes a query over the repository instead of an exercise in memory.
A mitigation phrased as "validate input" is not checkable and will be reported as done by whoever wrote it. A mitigation phrased as "reject any request where the tenant identifier in the body differs from the tenant in the token, and cover it with a test that sends a mismatched pair" is checkable by someone who was not in the session. The wording is the deliverable, not a formality.
Some mitigations are not code at all: a decision not to expose an endpoint, a rule that one queue is written by exactly one service, a choice to keep a component off the public subnet. Nothing in the build fails when someone quietly violates those, so they need a different home, usually a review item on that area of the system or a check in whatever provisions the infrastructure. Writing them down as if they were code changes is how they get lost.
What Counts as a Change Worth Reopening
Revisiting a model is a diff, not a rerun. Put the current diagram beside the one on file and look only at what moved: a new arrow, a new store, a boundary in a different place. Most reviews are short, because most changes stay inside a boundary that was already reasoned about, and the ones that take an hour are exactly the ones that needed it.
The trigger is rarely the size of the change. A one-line configuration edit can move a trust boundary while a large refactor moves nothing. Changes that justify reopening the model:
- A new external interface: a webhook receiver, a public endpoint, a partner integration, an admin API.
- A new class of data stored: payment details, health records, government identifiers, credentials.
- A change in who can call something, such as an internal service now reachable from a customer facing app.
- A new dependency that executes in your process or your build, including a CI action or a plugin.
- An authentication or authorization change: a new identity provider, a new token format, a new role.
- A deployment change that moves a component across a boundary, such as a private subnet to a managed service, or one tenancy model to another.
Frequently Asked Questions
Is threat modeling the same as a penetration test or a vulnerability scan?
No, and none of the three substitutes for the others. A scanner matches known bug patterns in code or in running services, and a penetration test attacks a build that already exists. Threat modeling works on the design, which means it can run before anything is built, and its output is decisions rather than findings. It catches flaws with no signature, such as an endpoint that trusts a client supplied identifier or a queue any service can write to, and it will happily miss an injection bug a scanner would flag in seconds.
Who needs to be in the room?
Three kinds of knowledge: someone who knows the code, someone who knows how the thing is actually deployed, and someone who knows what the data is worth to an outsider. On a small team that can be two people covering three roles; what matters is that every question asked has an answer present, not headcount. If nobody can say how the service authenticates a caller, stop and find that out before continuing, because every threat named after that point is a guess.
What should already be in place so the session stays on design?
A way to draw the system, and settled answers to how authentication works, where secrets are stored, and which external services get called. It also helps to have the basics handled first: dependency updates, multi-factor authentication on admin accounts, no credentials committed to the repository, TLS on internal hops. Those are cheaper to fix directly than to discover mid-conversation, and having them out of the way keeps the discussion on design questions instead of on housekeeping.
Do we need a threat modeling tool?
A tool earns its place when you want the model to change along with the code instead of sitting in a photograph of a whiteboard. OWASP Threat Dragon keeps the diagram and its threats in a JSON file. pytm describes the system in Python and generates the data flow diagram and a report from that description. Mermaid or PlantUML gives you a text diagram that renders in most repository viewers. The property that matters in all of them is a file version control can diff, so a change to the system shows up in a pull request next to the code change that caused it.
How does STRIDE compare to attack trees?
Attack trees run in the opposite direction: put the attacker's goal at the root, then enumerate the alternative ways to reach it as AND and OR branches. That shape is better when you already know which asset matters and want depth on the paths to it, and it supports rough quantitative reasoning, since you can annotate branches with cost, required skill, or likelihood of detection. STRIDE goes breadth first across the system and is better at surfacing threats nobody thought to name. Trees grow quickly and need maintenance, so teams that use them usually build one or two around the highest value target rather than for the whole system.
How does this fit into an existing development process?
It attaches to design rather than to release. The natural trigger is the moment a design is written down and before implementation starts, plus a review whenever the diagram stops matching reality. The model itself runs nowhere and depends on no particular pipeline or hosting; it belongs in the repository beside the code it describes. The one integration worth setting up is a link from threat identifiers to whatever tracks work, so an outstanding mitigation or an accepted risk is visible in the same place as everything else.
What does the team have to decide rather than a facilitator?
Which data actually matters, and what the organization is prepared to live with. A facilitator can draw the diagram, run the four questions, and press on vague answers, but calls such as accepting account enumeration on a login endpoint, or judging a data set not sensitive enough to encrypt at rest, are business decisions that need an owner inside the company. The team also decides who takes each follow-up and by when. A session that ends without names attached produces a document nobody returns to.