Threat modeling has a reputation problem. It's widely understood to be valuable — the idea of systematically thinking through how something could be attacked before you build it is obviously sensible. And yet the majority of engineering teams either don't do it, do it once and never revisit it, or do it in a format so heavy it produces documentation nobody reads.
The most common objection I hear from engineering teams: "We don't have anyone with AppSec expertise to run it." That objection is understandable, and it's also mostly wrong. You don't need a CISSP. You need a structured conversation and 90 minutes.
Why the expertise barrier is overblown
The formal threat modeling methodologies — STRIDE, PASTA, Attack Trees, VAST — have real value, but they were designed for contexts where you have time, resources, and dedicated security professionals. For a 15-engineer product company doing two-week sprints, trying to run full PASTA (Process for Attack Simulation and Threat Analysis) on every feature is a path to abandonment.
STRIDE, developed at Microsoft in the late 1990s, is the most accessible starting point for engineering teams without dedicated security staff. The six categories — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — map well to the threat categories that appear repeatedly in real incident post-mortems. More importantly, they're concrete enough that non-security engineers can apply them without expert facilitation.
The insight that most threat modeling trainers don't say loudly enough: engineers already understand threats. They just don't use security vocabulary for them. An engineer who says "what if someone passes a malicious JWT in that endpoint?" is doing threat modeling. The framework's job is to make that thinking systematic and ensure you're not missing entire categories.
The 90-minute STRIDE-light session
Here's the format that works for teams new to threat modeling. Block 90 minutes. Include the engineers who built or are building the feature, the tech lead, and if available a product manager who understands the user model.
Start with 15 minutes drawing the data flow diagram. Not a full architecture diagram — just: what data enters this system, what touches it, where does it go, what's the trust boundary between "user controls this" and "we control this"? A whiteboard or shared Miro board works fine. The diagram doesn't need to be complete, it needs to be a shared model.
Then spend 60 minutes running STRIDE against each trust boundary crossing. For each data flow that crosses a trust boundary, ask six questions: Can this flow be spoofed? Can the data be tampered with in transit? Can the requester deny having made the request? Is there information exposed in this flow that shouldn't be? Can this flow be used to cause denial of service? Can this flow be used to gain elevated privilege?
Not every question will be relevant to every boundary. That's fine. You're looking for the ones where the answer is "actually, yes, that's possible and we haven't addressed it." Write those down. They become findings.
The final 15 minutes are for triage. Which findings are high-risk enough to address in the current sprint? Which go to the backlog? Which are acceptable risks given current context? Those decisions should be made by the team, not delegated to a security team to review six weeks later.
Common failure modes in first sessions
The first time an engineering team runs a threat modeling session, a few predictable things happen:
The data flow diagram takes too long. Engineers want to get it exactly right. The diagram doesn't need to be exact — it needs to be good enough to surface trust boundaries. Timebox it to 15 minutes and move on even if it's incomplete. A 70% complete diagram that generates real findings is better than a 100% complete diagram that takes the entire session to produce.
The team gets stuck on "but this is already handled by our framework." Rails has CSRF protection. Django handles SQL parameterization. Acknowledge that and move on — the goal is to find what the framework doesn't handle for you, not to re-litigate what it does.
The findings list is either empty or enormous. An empty list usually means the team isn't thinking adversarially enough — they're asking "could this happen in our system?" rather than "how would an attacker make this happen?" An enormous list usually means the team is conflating security issues with general code quality issues. Keep the scope narrow: findings are about security impact, not code cleanliness.
What to do with the output
This is where many threat modeling programs fail. The session produces findings. Those findings go into a document. The document lives in Confluence. Six months later, nobody has acted on any of them because they were never translated into actual work items.
The discipline is to convert every accepted finding into a JIRA ticket (or GitHub Issue, or whatever your team uses) before the session ends. Assign it. Give it a priority. If it's not important enough to be a ticket, it's not important enough to be a finding — cross it off the list.
We're not saying every threat needs to be fixed immediately. That's not realistic. We're saying every threat that's accepted as real and in-scope needs to be tracked as work, not as documentation. The difference between a threat modeling program that works and one that doesn't is usually whether the output lives in your backlog or in a document nobody revisits.
Scaling up: when to add more structure
The STRIDE-light session described here is a starting point, not a ceiling. As your team develops the habit, a few additions compound the value significantly:
Attack trees for high-value targets. For your authentication system, your payment processing flow, your data export functionality — anywhere an attacker would focus disproportionate attention — a more structured attack tree analysis is worth the extra time. OWASP's threat modeling resources provide good templates for these.
Per-feature threat models over time. The most mature threat modeling programs run a short session at the design phase of every significant feature, and revisit the model when the feature changes substantially. This creates a threat modeling culture rather than a one-time exercise.
Consider a 30-engineer SaaS company in 2024 preparing for a SOC 2 Type II audit. They had never run a formal threat modeling session. In two months of running STRIDE-light sessions against their four highest-risk features, they identified eleven findings — three of which were high severity. Two of those high-severity findings would have been directly relevant to the audit trust service criteria. The sessions cost them roughly 20 engineer-hours total. The alternative — discovering those issues during an audit or in a post-incident review — would have been substantially more expensive.
You don't need an AppSec team to start threat modeling. You need a team willing to think adversarially about what they're building. The framework is just structure for a conversation your engineers are already capable of having.
