Stop Asking “Which Threat Modeling Method Is Best.” Ask What It’s Centered On.
Every AppSec engineer learns STRIDE at some point, and a lot of us quietly stop there. It’s the first threat modeling method most of us meet; it’s teachable in an afternoon, and it maps cleanly onto a data flow diagram — so it becomes the hammer, and every system starts looking like a nail.
The problem isn’t STRIDE. STRIDE is a genuinely good method for what it does. The problem is treating “which method is best” as a real question, the way people ask “which programming language is best.” It’s the wrong axis. The useful question is: what does this method center? Once you can answer that for each one, method selection stops being a matter of taste and starts being a matter of matching the lens to the system in front of you.
What each method actually centers
STRIDE centers the design — what can go wrong at each component in a data flow diagram. It’s a workhorse: low barrier to entry, teachable to developers who’ve never done this before, great at eliciting technical threats quickly. Its blind spots are just as real as its strengths, though. It has no concept of business context, so it can’t tell you which of the two hundred threats it just generated actually matters to your organization. And it’s blind to privacy in a specific, easy-to-miss way — STRIDE will flag “information disclosure” the moment data can leak, but it has nothing to say about whether that data being linkable across two systems constitutes a privacy harm, or whether a user ever consented to it being used that way. Disclosure and privacy harm are not the same question, and STRIDE only asks the first one.
PASTA centers the business and the attacker. It’s the only mainstream method that starts from business objectives and walks all the way through to quantified risk, which is exactly why it’s the one method that speaks fluently to a board or to GRC. It pulls in real threat intel and your existing SAST/DAST findings rather than working in the abstract. The cost is that it’s heavy — it needs senior facilitation, cross-functional input, and real time, and none of that scales to a Tuesday sprint. PASTA is the right call for the 5% of systems where the stakes justify a genuinely expensive process: a payments engine, a system your board is already nervous about, anything where you need to justify risk to leadership with real rigor behind it.
LINDDUN centers the data subject — the actual human whose data is moving through your system, not your system’s components. This is the one most security-only teams underrate, because STRIDE’s “information disclosure” feels like it already covers privacy, and it doesn’t. LINDDUN asks whether two anonymized records can be linked back to the same person, whether “anonymized” data can actually be re-identified, and whether the subject ever knew or consented to any of it. If you’re processing PII or PHI at scale, or you’re GDPR- or CCPA-bound, this isn’t an optional extra layer — it’s a disjoint threat space from STRIDE, and you need both, run in parallel on the same diagram, not one instead of the other.
Attack trees center a single, specific attacker goal — “forge a payment,” “compromise the signing key” — decomposed into every path that could achieve it, with each leaf annotated by cost, skill, and detectability. This is where you go deep once a breadth method has already told you what the two or three crown-jewel goals are. It doesn’t scale to whole-system coverage, and it’s only as good as the analyst’s imagination for branches, but for drilling into one high-value objective, nothing else gets you that close to a red team’s actual thinking.
Kill Chain / MITRE ATT&CK-based modeling centers the adversary’s real operational playbook — reconnaissance through exfiltration, grounded in observed behavior rather than imagined threats. Its superpower is that it bridges threat modeling directly into detection: every technique maps to something your SOC can actually watch for. Its limitation is that it’s a runtime lens — it presumes a system already exists to attack, so it’s a poor fit for design-time elicitation, and it can quietly drift into pure detection engineering if you’re not careful.
Get Prianshu Bhaskar’s stories in your inbox
Join Medium for free to get updates from this writer.
VAST centers scale and process — how you run threat modeling across 200 engineers and 40 microservices without an expert sitting in every room. It’s less a crisp technique than a philosophy, closer to a program design than an analysis method, and it can produce shallow output if the automation around it substitutes for actual thinking. But it’s the honest answer to the question every growing security team eventually asks: how do we make this a living practice instead of a one-off document nobody reads?
The methods aren’t competing — they compose
Once you see it this way, the real skill isn’t picking a favorite. It’s layering: STRIDE for breadth across a system, then attack trees to go deep on whatever crown jewels STRIDE surfaced. STRIDE and LINDDUN run in parallel on the same diagram, because they cover disjoint ground. STRIDE at design time, ATT&CK overlaid once the system is deployed, to drive real detections. VAST as the scaffolding that carries lightweight STRIDE across the 95% of ordinary changes, with PASTA reserved for the handful of systems where the business stakes actually warrant it.
A concrete case worth sitting with: a healthcare startup ingesting hospital patient records to train a diagnostic model, then selling API access to third-party clinics — small team, tight timeline, GDPR and HIPAA both in scope. The instinct is to reach for PASTA because the compliance stakes sound serious. But the constraint that actually matters here is the small team and the tight timeline, and that constraint rules PASTA out before you’ve even started — it forces you toward lightweight STRIDE plus a leaner LINDDUN pass, scoped tightly to the flows that matter: data ingestion, the training pipeline, and the multi-tenant API. And notice what a generic STRIDE pass would miss entirely if you didn’t read the system carefully: training a model on patient data opens up model inversion and membership inference — an attacker with API access inferring whether a specific patient’s record was in the training set — which is as much a LINDDUN concern (identifiability) as it is a security one. STRIDE, run on autopilot, will never surface that on its own.
The trap question
Here’s the version of this argument I’d expect to actually come up in an interview or a design review: a colleague says PASTA is just strictly better than STRIDE — more thorough, includes business risk, has an actual analysis stage — so why not standardize on PASTA everywhere and retire STRIDE?
The flaw is that “more thorough” quietly assumes thoroughness is a single, orderable quantity, and it isn’t. PASTA isn’t more thorough than LINDDUN on privacy — it has no privacy machinery at all — and it isn’t more thorough than an attack tree on the depth of one specific goal. Every method is thorough along its own axis, and there’s no total ordering across axes.
But the sharper problem is what happens when you actually try to run PASTA on everything. A standard nobody can sustain doesn’t get done thoroughly — it gets skipped, or rubber-stamped, or quietly faked. A lightweight method that genuinely runs on every change beats a heavyweight one that runs on ten percent of them and gets theater’d on the rest, because security outcome is roughly depth multiplied by coverage, and you’ve just traded coverage for depth-on-paper. Worse, PASTA needs scarce, senior facilitators — standardize on it everywhere and the handful of people who can actually run it become a hard ceiling on how much threat modeling the entire org can do. You’ve turned your best people into the bottleneck for a practice that was supposed to scale past them.
That’s the actual argument for matching method to context instead of picking a favorite: not “STRIDE is better” or “PASTA is better,” but that a method mismatched to its constraints doesn’t just underperform — it can quietly teach an organization that threat modeling is bureaucratic overhead, and that lesson is much harder to undo than a bad first attempt.
This continues a series on practical application security and threat modeling. If your last threat model was picked by habit rather than by what it needed to cover, it might be worth asking what it was actually centered on.
Follow me on LinkedIn: https://www.linkedin.com/in/prianshu-bhaskar/
