skip to content
Search through blog posts and articles. Use arrow keys to navigate results, Enter to select, and Escape to close.

Search

Practical Threat Modeling with STRIDE in Software Development

3 min read

A practical guide to using STRIDE for threat modeling in software development, showing how early security thinking prevents risks and improves design decisions.

#software development#security#stride#devsecops

In today’s complex software landscape, security must be built in-not bolted on. Threat Modeling1 helps teams surface design level of risks early, reducing blind spots before code is deployed.

Frameworks like STRIDE, PASTA, or OCTAVE provide repeatable ways to identify and categorize threats. This article focuses on STRIDE, based on my experience applying it in a key application project at NN Bank, but the approach is broadly relevant.

Why It Matters

Security flaws often stem from missed assumptions, not just bugs. Threat modeling forces teams to ask: What can go wrong? Where are we exposed? How do we respond?

Done well, it:

  • Surfaces gaps before implementation

  • Encourages shared language across teams

  • Drives secure by design thinking

STRIDE in Practice

STRIDE categorizes threats into six types: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege and during architecture discussions, it helped us:

  • Catch authentication risks early

  • Challenge trust boundaries

  • Improve decision making on controls and mitigations

  • Spotlight data flow and privacy concerns of the customers

In the example section, a sample question per threat shows us the required mindset and how to challenge a threat by considering characteristics of participants within a business flow.

Example: File Upload and Sharing

A system allows users to upload PDF documents and share them via public or private links. Here’s how STRIDE helps to evaluate its security posture:

Spoofing

Threat: Could someone impersonate another user?

  • Authentication tokens were not tied to session context or device fingerprint.

  • File ownership was not verified during link access.

Tampering

Threat: Could files be modified after upload?

  • No integrity checks on file content.

Repudiation

Threat: Could a user deny uploading or sharing a file?

  • No audit logs were implemented.

Information Disclosure

Threat: Could unauthorized users access files?

  • UUID based links were long but had no expiration or scoping.

Denial of Service

Threat: Could someone overload the system with uploads?

  • No limits on file size or number of uploads per user.

Elevation of Privilege

Threat: Could users gain unauthorized capabilities?

  • Some file metadata operations lacked role based access checks.

Key Lessons

I think the biggest takeaway is consistency beats complexity and what matters most is not which framework you use but that you use one. Successful threat modeling is:

  • Knowledge: grounded in understanding the system and its business goals

  • Scheduled: tied to planning cycles (twice a year or yearly)

  • Collaborative: involving engineering, product, and security

  • Actionable: leading to real design adjustments

We made it a ritual, revisiting key flows and threat surfaces as the system evolved.

Final Thought

Whether you adopt STRIDE or a custom model, start modeling threats early and often. The earlier risks are visible, the easier they are to manage. I believe security isn’t just a checklist and it’s how you think.

Footnotes

  1. Threat Modeling on Wikipedia ⤴