STRIDE vs. Attack Trees: Two Lenses for Threat Modeling

Threat modeling has evolved from a niche security task into a core part of modern software development. It’s not just for security engineers — it’s a tool product teams, developers, and architects can use to ask the most important question in software design:

“What could go wrong?”

Two of the most commonly used models for answering that question are STRIDE and Attack Trees. They approach the problem from different angles, but they both help teams think like an attacker and spot weaknesses before they’re exploited.

Let’s walk through what each model brings to the table, how they differ, and how you can use them — even if you don’t have a full-time security expert embedded in your team.

The STRIDE Model: Categorising the Enemy

STRIDE is a mnemonic created by Microsoft to help teams identify threats in six broad categories. Each threat is a violation of a desirable property for a system:

Threat	Desired property	Threat Definition
Spoofing	Authenticity	Pretending to be something or someone other than yourself
Tampering	Integrity	Modifying something on disk, network, memory, or elsewhere
Repudiation	Non-repudiability	Claiming that you didn’t do something or were not responsible; can be honest or false
Information Disclosure	Confidentiality	Someone obtaining information they are not authorised to access
Denial of Service	Availability	Exhausting resources needed to provide service
Elevation of Privilege	Authorisation	Allowing someone to do something they are not authorised to do

What makes STRIDE useful is that it provides a systematic way to interrogate each component of your system. You can apply it to user flows, data stores, APIs, microservices — asking for each: “Can this be spoofed? Tampered with? Abused to elevate privilege?”

For example, if you’re designing a new internal admin dashboard, STRIDE encourages you to think not just about whether the login form works, but:

• Could someone fake an admin session (spoofing)?
• Could an attacker alter API responses (tampering)?
• Will actions be properly logged (repudiation)?
• Is sensitive customer data at risk (disclosure)?
• Could a broken feature be abused to crash the system (DoS)?
• Can a regular user do admin-only things (privilege escalation)?

In practice, STRIDE works best early in the design phase, especially when you’re diagramming architecture. It’s great for uncovering broad categories of risk you might otherwise overlook.

Attack Trees: Thinking Like an Adversary

While STRIDE helps you classify threats, Attack Trees help you map how those threats might actually happen.

An attack tree starts with a goal an attacker wants to achieve — say, “Access user payment data”. From there, you branch downward, listing different ways they might reach that goal. Each branch explores alternate tactics, such as:

• Gaining access to the database
• Exploiting a SQL injection vulnerability
• Reusing leaked database credentials
• Bypassing authentication
• Phishing an admin
• Exploiting a logic flaw in the login flow

The tree can grow quite large, and that’s a feature, not a bug. You’re building a map of your system from the attacker’s perspective.

Attack Trees are especially useful when analysing specific high-value assets or scenarios, like “delete all customer data” or “impersonate another user.” They force teams to walk through the attack step by step, thinking in terms of real-world tactics and dependencies.

Where STRIDE is abstract and category-driven, Attack Trees are concrete and scenario-driven. They’re a natural fit for post-design reviews, red team planning, and focused security exercises.

So Which One Should Your Team Use?

It’s not about choosing one or the other. It’s about matching the model to your team’s maturity and the questions you’re trying to answer.

Use STRIDE when:

• You’re in the architecture or design phase
• You want to make sure you’ve considered the full landscape of threat types
• Your team is new to threat modeling and needs a structured entry point
• You’re working on something complex (like a new service or feature) and want a checklist-style approach

Use Attack Trees when:

• You’re concerned about a particular high-risk goal or asset
• You want to simulate how an attacker might chain vulnerabilities together
• You’re preparing for a red team or tabletop exercise
• You want to prioritise which attack paths are easiest to execute and should be mitigated first

A mature security-minded team will often use both: STRIDE to guide high-level threat enumeration, then Attack Trees to go deep on what matters most.

Where Product Teams Fit In

If you’re a PM, designer, or engineer working on product features, don’t leave threat modeling to security alone. You understand the real-world usage of your feature, the edge cases, the hidden complexity, and that context is essential.

For example:

• You might know that a “temporary admin” role exists for internal support. But no one thought to expire it.
• Or that the front-end restricts file uploads to .jpg, but the back-end happily stores .exe files.
• Or that the “delete my account” flow doesn’t check whether the requester owns the account being deleted.

By engaging in a STRIDE or Attack Tree session, you bring usability, business logic, and implementation realities into the security conversation.

You don’t need to be an expert in XSS or encryption algorithms. You just need to be curious enough to ask:

“If I were trying to break this — how would I do it?”

Final Thoughts

STRIDE and Attack Trees aren’t competing tools; they’re complementary ways to stretch your team’s security mindset. One gives you a structured checklist; the other gives you a dynamic playbook.

As threat modeling becomes more accessible, it’s no longer just a checkbox for compliance or a one-time design step. It’s a way of thinking that strengthens your product at every phase.

So next time you’re launching a new feature, don’t just ask “Is it done?” Ask: “How could it go wrong?” And then sit down as a team to find out, before someone else does.