The Comprehensive Guide to Threat Modeling in the SDLC: Why It Matters and How to Start
Threat Modeling is the backbone of truly secure software development. Learn why it is critical for SDLC, explore common threat examples using the STRIDE framework, and download our free, actionable Threat Modeling checklist to secure your applications from day one.
Every penetration test report contains findings that should never have existed. Not coding mistakes — design decisions. A trust boundary nobody identified, an authorisation model that assumed something untrue, a workflow that can be completed out of order. These are expensive to fix late and nearly free to avoid early.
Threat modelling is the practice of finding them before the code exists. It has a reputation for being heavyweight and academic, which is largely a reaction to how it is often taught: elaborate diagrams, exhaustive enumeration, a document nobody reads. Done well it is a structured conversation lasting an hour or two, producing a short list of concrete decisions.
This guide covers what threat modelling actually involves, the four questions that carry most of the value, when to do it and when not to bother, how to fit it into an existing SDLC without slowing delivery, and what changes when AI features are in scope.
- 01Threat modelling finds design flaws — the class no scanner or code review will ever catch.
- 02Four questions carry the value: what are we building, what can go wrong, what will we do, did it work.
- 03Model trust boundaries, not components. Risk concentrates where data crosses between them.
- 04Output is tracked work items, not a document. A model in a wiki changes nothing.
- 05Trigger on significant change — new features, new integrations, new data — not every sprint.
The Class of Flaw Nothing Else Finds
It is worth being precise about why this practice exists, because it fills a genuine gap rather than duplicating other controls.
| Control | Finds | Cannot find |
|---|---|---|
| Static analysis | Insecure patterns in written code | Flaws in what the code was asked to do |
| Code review | Implementation errors and weak logic | A missing control nobody specified |
| Penetration testing | Exploitable flaws in a running system | Anything before the system exists |
| Threat modelling | Design flaws, missing controls, wrong assumptions | Implementation bugs in the resulting code |
The distinction matters commercially. If a design omits an authorisation check between tenants entirely, no tool reports it as a defect — the code correctly implements a flawed specification. It surfaces later as a critical penetration test finding requiring architectural rework, or as an incident.
The Four Questions
Strip away the methodology debates and threat modelling is four questions, asked in order.
What are we building? A diagram sufficient to reason about — components, data flows, and critically the trust boundaries between them. Whiteboard quality is fine; the goal is shared understanding, not documentation.
What can go wrong? The structured part. Walk each trust boundary and ask what an attacker could attempt. STRIDE — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege — is a useful prompt because it stops the conversation defaulting to whatever the team already worries about.
What are we going to do about it? For each realistic threat: mitigate, transfer, accept explicitly, or eliminate by changing the design. Accepting a risk is a legitimate answer when it is deliberate and recorded.
Did we do a good job? Review after implementation. Were the mitigations built? Did a penetration test later find something the model should have anticipated? This is the loop that makes the practice improve rather than ossify.
The most common failure: stopping after question two. Teams enumerate threats thoroughly, produce a comprehensive document, and never convert it into tracked work. A threat model that does not create backlog items with owners has changed nothing except the amount of time spent.
Model Boundaries, Not Components
The single most useful technique is to focus on trust boundaries — the points where data or control passes between things with different trust levels.
Between the internet and your application. Between an authenticated user and an administrative function. Between one tenant's data and another's. Between your service and a third party. Between an application and its database. Risk concentrates at these crossings because that is where assumptions get made, and it is at these crossings that the highest-impact findings in real engagements almost always sit.
Modelling components individually produces long, low-value lists. Modelling boundaries produces a short list of decisions that matter.
Fitting It Into Delivery
The most common objection is that it slows teams down. That is true of the heavyweight version and avoidable in practice.
| Trigger | Depth | Typical effort |
|---|---|---|
| New product or major architecture | Full model with all four questions | Half a day to a day |
| New feature crossing a trust boundary | Focused model on the affected boundary | One to two hours |
| New third-party integration | Data flow and trust assumptions only | An hour |
| New category of data | Classification, retention and access review | An hour |
| Routine change within existing patterns | None required | — |
The last row is the one that makes the practice sustainable. Threat modelling every sprint regardless of change produces fatigue and theatre. Trigger on genuine change and teams engage, because the exercise visibly earns its time.
Two practical points. Developers should run the session with security support, not the reverse — a model produced for a team is discussed once and forgotten, while one produced by the team shapes their decisions. And the output belongs in your existing backlog with owners and priorities, not in a separate security document.
When AI Features Are in Scope
AI components introduce trust boundaries that conventional modelling does not anticipate, and they deserve explicit attention.
A model that reads untrusted content — a document, a web page, an email — has an input channel where instructions and data are indistinguishable by design. Prompt injection has no clean structural fix, so the modelling question shifts from "can it be manipulated" to "what is it permitted to do once it has been". Every tool the model can call, every system it can reach, and every irreversible action it can trigger belongs on the diagram as a distinct boundary.
Retrieval systems add a second consideration: whether the retrieval layer filters against the requesting user's own permissions, or whether the model can surface anything in the corpus to anyone who asks well enough. Our generative AI security guide covers the testing side.
A Starting Checklist
- 01Pick one upcoming feature that crosses a trust boundary — not your whole platform.
- 02Get the engineers who will build it in the room, with security supporting.
- 03Draw the data flow and mark every trust boundary. Whiteboard quality is fine.
- 04Walk each boundary with STRIDE as a prompt, not a form to complete.
- 05Decide mitigate, transfer, accept or eliminate for each realistic threat.
- 06Create backlog items with owners — this is the step that makes it real.
- 07Record accepted risks explicitly, with who accepted them and why.
- 08Revisit after the next penetration test — did the model anticipate what was found?
How Adayptus Helps
- Threat Modeling — facilitated sessions with your engineers, producing tracked decisions.
- Secure Code Review — verifying the mitigations were actually built as designed.
- Web Application and API Penetration Testing — validating the result, with a free retest.
- AppSec Maturity Assessment — where threat modelling fits into a broader programme.
- AI & LLM Security Assessment — for the boundaries AI features introduce.
Related reading: secure code review guide and web application penetration testing.
Frequently Asked Questions
Click any question to expand the answer.
QWhat does threat modelling find that other controls miss?
Design flaws — missing controls, wrong trust assumptions, workflows that can be abused as specified. If a design omits an authorisation check between tenants entirely, no scanner or code review reports a defect, because the code correctly implements a flawed specification. That gap surfaces later as a critical penetration test finding requiring architectural rework, or as an incident. Threat modelling is the only control that operates before the system exists.
QDo we need to threat model every sprint?
No, and doing so produces fatigue and theatre. Trigger on genuine change: a new product or major architecture warrants a full model, a feature crossing a trust boundary warrants a focused one to two hour session, and a new integration or data category warrants an hour. Routine changes within existing patterns need nothing. Teams engage with the practice when it visibly earns its time and disengage when it becomes a ritual.
QIs STRIDE still the right methodology?
It remains a useful prompt rather than a mandatory framework. Its value is that it stops a session defaulting to whatever the team already worries about — walking spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege at each trust boundary surfaces categories that would otherwise be skipped. Treat it as a checklist for the conversation, not a form to complete, and the session stays productive.
QWho should run a threat modelling session?
The engineers who will build the system, with security facilitating rather than leading. A model produced for a team is discussed once and forgotten; one produced by the team shapes the decisions they make while writing the code. Security's role is to ask the questions the team would not think to ask and to ensure outcomes become tracked work — not to hand over a document.
QHow does threat modelling change for AI features?
A model reading untrusted content has an input channel where instructions and data are indistinguishable by design, and prompt injection has no clean structural fix. So the question shifts from whether it can be manipulated — assume it can — to what it is permitted to do once it has been. Put every tool the model can call, every system it can reach and every irreversible action on the diagram as a distinct boundary, and check that retrieval filters against the requesting user's own permissions.
QWhy do threat modelling programmes fail?
Most commonly by stopping after threat enumeration. Teams identify threats thoroughly, produce a comprehensive document, and never convert it into tracked work with owners — so nothing changes except the time spent. The second failure is over-scoping: attempting to model an entire platform rather than one feature, which produces an exercise so large it is never repeated. Start small, finish the loop, and let the practice earn its place.
Adayptus Security Research
Strategic Intelligence Division
Adayptus Consulting is a premier provider of enterprise cybersecurity solutions, specializing in Managed SOC, Penetration Testing, and GRC strategy. Our intelligence division regularly publishes research to help CISOs navigate the evolving threat landscape.
