Threat modeling has a reputation problem. Developers picture a two-day workshop with a security consultant, a wall of sticky notes, and a 40-page document that gets filed and never opened. So they skip it, and design flaws — the most expensive class of vulnerability, because they're baked into the architecture rather than sitting in a line of code — sail straight through to production, where no scanner will catch them. The truth is that threat modeling is just structured paranoia applied at design time, and a useful version of it fits inside a normal feature discussion. You don't need a framework certification. You need to ask four questions about the thing you're building, before you build it, while changing the design is still cheap.
The four questions that are the whole method
Adam Shostack's four-question framework is the most durable formulation of threat modeling, and for most feature-level work it's all you need:
- What are we building? Draw the system — components, data stores, external actors, and the data flowing between them. A rough data-flow diagram on a whiteboard is enough. The act of drawing it surfaces trust boundaries you hadn't consciously noticed.
- What can go wrong? Walk the diagram and enumerate threats. This is where STRIDE (below) gives you a checklist so you don't just rely on imagination.
- What are we going to do about it? For each credible threat, decide: mitigate, eliminate (remove the feature/data), transfer, or knowingly accept.
- Did we do a good job? Review the model against what actually got built, and revisit it when the design changes materially.
The discipline is in doing this before the code exists, when moving a trust boundary is a conversation rather than a re-architecture.
Use STRIDE to answer "what can go wrong?"
STRIDE, from Microsoft, is a mnemonic that turns "what can go wrong?" from an open-ended stare into a systematic pass. For each element and data flow, ask whether each threat category applies:
| Letter | Threat | Violates | Example question |
|---|---|---|---|
| S | Spoofing | Authentication | Can someone pretend to be another user or service? |
| T | Tampering | Integrity | Can data be modified in transit or at rest? |
| R | Repudiation | Non-repudiation | Can someone deny an action with no audit trail? |
| I | Information disclosure | Confidentiality | Can data leak to someone unauthorized? |
| D | Denial of service | Availability | Can someone exhaust or crash the service? |
| E | Elevation of privilege | Authorization | Can a user gain rights they shouldn't have? |
Trust boundaries — the lines where data crosses from a less-trusted zone to a more-trusted one (internet to API, service to database, tenant to tenant) — are where threats concentrate. Focus STRIDE effort there.
A worked example
Say you're adding a feature that lets users export their account data to a downloadable file generated by a background worker and served from object storage.
- What are we building? Browser → API (authn) → job queue → worker → object storage → signed download URL back to the browser. Trust boundaries: internet↔API, worker↔storage.
- What can go wrong (STRIDE)?
- Spoofing / Elevation: Can user A request an export of user B's data by changing an ID? (authorization on the export request)
- Information disclosure: Is the download URL guessable or long-lived enough to be shared/leaked? (short-lived signed URLs, scoped to the requester)
- Tampering: Can the job payload be manipulated to export a different account? (sign/validate job payloads server-side)
- Denial of service: Can someone queue thousands of expensive exports? (rate-limit, quota)
- Repudiation: Is the export action logged with actor and target? (audit log)
- What do we do? Enforce per-resource authorization on the request, issue time-boxed signed URLs, validate job payloads server-side, rate-limit, and log the action.
That entire exercise takes twenty minutes and catches design flaws that would otherwise become an IDOR CVE and a data-exposure incident.
Make it a habit, not an event
Threat modeling delivers value in proportion to how routine it is. Attach a lightweight model to the design doc for any feature that touches a trust boundary, handles sensitive data, or changes authentication/authorization. Keep it in version control next to the code so it evolves with the system. And connect it to your testing: the threats you identified become test cases and things to verify with dynamic application security testing against the running feature, while the mitigations that involve dependencies get checked by software composition analysis. A threat model that never gets validated against the running system is a guess; one that drives your DAST and test coverage is a control.
Where to invest deeper
For high-risk systems — payment flows, authentication services, anything multi-tenant — go beyond the lightweight pass. Consider attack trees for critical assets, use the MITRE ATT&CK catalog to reason about how a real adversary would chain steps, and bring in the central AppSec team or a security champion. Threat modeling scales with risk: twenty minutes on a routine feature, a dedicated session on the thing that would end up in the news if it broke.
How Safeguard Helps
Safeguard turns a threat model from a static document into enforced controls. The dependency-related mitigations you identify are continuously verified by reachability-aware SCA, and the runtime behaviors you're worried about — exposed endpoints, injection, broken access control — are exercised by DAST against your deployed environment. Griffin AI reviews pull requests against the threats you flagged, so a missing authorization check or an unsafe deserialization surfaces in review rather than in an incident. If you're comparing depth of analysis against a traditional SAST-heavy tool, our Safeguard vs Checkmarx comparison is a useful reference.
Validate your threat models against real behavior free at app.safeguard.sh/register, or read the DAST and scanning docs at docs.safeguard.sh.