STRIDE is a threat-modeling framework that gives you six specific categories to check every part of a system against, so a threat brainstorm becomes systematic instead of a test of who in the room is most imaginative. Developed at Microsoft in the late 1990s, the acronym stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. Its power is simple: point STRIDE at any element in a data flow diagram, ask "is this vulnerable to each of the six?", and you convert a vague sense of unease into a concrete, prioritizable list of threats.
Why It Matters
The hardest part of threat modeling is the blank page. Ask a team "what could go wrong here?" and you get either silence or an unstructured pile of worst-case fantasies. STRIDE solves that by giving structure: six well-defined lenses that map cleanly to the security properties they violate. Each category is the negation of a property you want your system to have.
| STRIDE threat | Violates | Plain-English question |
|---|---|---|
| Spoofing | Authentication | Can someone pretend to be someone else? |
| Tampering | Integrity | Can data or code be modified in transit or at rest? |
| Repudiation | Non-repudiation | Can someone deny doing something with no proof otherwise? |
| Information disclosure | Confidentiality | Can data leak to someone who should not see it? |
| Denial of service | Availability | Can someone make the system unavailable? |
| Elevation of privilege | Authorization | Can someone gain rights they should not have? |
Because the six map to the classic security properties (authentication, integrity, non-repudiation, confidentiality, availability, authorization), STRIDE doubles as a completeness check. If you have not thought about all six for a sensitive element, you have a gap by definition.
How to Do It: STRIDE per Element
The most reliable way to apply STRIDE is "per element" — walk your data flow diagram and test each item against the categories that apply to its type. Not every category applies to every element, which keeps the exercise focused.
The type-to-threat mapping is the practical core of the method:
External entity → S, R
Process → S, T, R, I, D, E (all six)
Data flow → T, I, D
Data store → T, I, D (+ R if it holds logs)
Processes — your services and functions — are exposed to all six categories, so they get the most scrutiny. Data flows across a network are mainly at risk of tampering, disclosure, and denial. Data stores worry about integrity and confidentiality, plus repudiation if they hold audit logs.
A working session runs like this:
- Draw the diagram. Identify processes, data stores, data flows, external entities, and the trust boundaries between them.
- Pick an element and its applicable letters. For a login process, that is all six.
- Ask each question concretely. Not "could there be spoofing?" but "can an attacker replay a captured token to impersonate a user?"
- Record real threats and a proposed mitigation. Map each to a known control: authentication for S, integrity checks and signing for T, logging for R, encryption and access control for I, rate limiting and quotas for D, least privilege for E.
- Track the decision. Every credible threat becomes a requirement, a ticket, or a documented acceptance.
For example, applied to a message queue feeding a payments service: Tampering — can a message be altered in flight? Mitigation: signed messages with verification on consume. Spoofing — can a rogue producer inject messages? Mitigation: mutual TLS and per-producer credentials. Denial of service — can the queue be flooded? Mitigation: quotas and backpressure.
Common Pitfalls
- Forcing all six on every element. Applying elevation-of-privilege analysis to a static data flow wastes time and breeds cynicism about the method. Use the type mapping.
- Stopping at the category. "This is vulnerable to information disclosure" is not a threat; it is a heading. The threat is the specific path: which data, to whom, through what weakness.
- Confusing STRIDE with prioritization. STRIDE finds threats; it does not rank them. Pair it with a scoring approach (impact and likelihood, or DREAD if your team likes it) to decide what to fix first.
- Ignoring repudiation. It is the most-skipped category and the one auditors care about most. If you cannot prove who did what, you fail both incident response and compliance.
- Modeling once and filing it away. A new external integration adds new spoofing and tampering surface. Re-run STRIDE when the diagram changes.
How It Connects to Supply Chain Security
STRIDE was designed for systems you build, but its lenses translate directly to the software supply chain, where most of your code now comes from outside. A compromised dependency is Tampering with your build inputs. A typosquatted package impersonating a real one is Spoofing at the registry level. A malicious post-install script exfiltrating environment variables is Information disclosure. A build step that quietly grants a package broad permissions is Elevation of privilege. Running STRIDE against your build pipeline — treating each dependency edge and each CI step as an element — surfaces supply chain threats that code scanning alone will miss.
This is where STRIDE meets tooling. The Tampering and Spoofing questions about your dependencies are exactly what Software Composition Analysis answers, by inventorying every open source component and flagging tampered or malicious ones. The Information disclosure and Elevation of privilege threats you identify at design time can be validated against a running system with dynamic testing. And because a thorough STRIDE pass across a real architecture produces far more threats than a team can manually triage, Griffin AI correlates them with live findings so you fix the reachable, exploitable ones first. To place STRIDE alongside related frameworks, see our concepts library.
Safeguard treats the trust boundaries you drew during STRIDE as the boundaries it enforces continuously — so a tampering threat you mitigated in design stays mitigated as dependencies and pipelines change.
Create a free account to inventory your components, or read the documentation to connect STRIDE findings to continuous scanning.
Frequently Asked Questions
Is STRIDE outdated now that we have AI and cloud systems?
No — the six categories map to fundamental security properties that do not change with architecture. What changes is where you apply them. STRIDE against a cloud-native, dependency-heavy, AI-augmented system is as useful as ever; you simply add build pipelines, third-party APIs, and model endpoints to the elements you analyze.
How is STRIDE different from the OWASP Top 10?
STRIDE is a threat-enumeration framework you apply to a design; the OWASP Top 10 is a ranked list of common web-application weaknesses observed in the wild. STRIDE helps you discover threats systematically; the Top 10 tells you which real-world weaknesses are most prevalent. They complement each other — many Top 10 items are specific instances of a STRIDE category.
Do I need to score threats with DREAD as well?
Not necessarily. STRIDE enumerates threats but does not rank them, so you need some prioritization method. DREAD is one option, but many teams find a simple impact-times-likelihood matrix, or reachability-based prioritization, more practical and less subjective than DREAD's five-factor scoring.
Can STRIDE be automated?
Partly. Tools can generate candidate threats from a diagram and the type-to-threat mapping, and can flag supply chain instances like tampered dependencies automatically. But judging which threats are credible for your specific context still benefits from the engineers who understand the system. Automation scales the enumeration; humans still make the calls.