What is Threat Modeling?

By Tony UcedaVélez, CEO of VerSprite and co-creator of the PASTA threat modeling methodology. Last reviewed: August 2026.

Threat modeling is a structured process for identifying, analyzing, and prioritizing the ways a system could be attacked before it’s built, or before the next thing gets added to it. A team maps out what the system is, what could go wrong with it, and what to do about each risk, using one of several established methodologies (STRIDE, PASTA, LINDDUN, attack trees, or VAST, among others). The output is a prioritized list of threats and mitigations that feeds directly into design decisions, code review, and security testing done early enough that fixing a problem costs a design change rather than a production incident.

That’s the short version. The rest of this page covers where threat modeling fits in the development lifecycle, what goes into one and what comes out, who needs to be in the room, and because “threat modeling” isn’t one fixed procedure an even-handed look at the five methodologies teams actually use, including where each one is the better fit.

The Core Definition

Threat modeling asks four questions about a system, in this order:

1. What are we building? — the architecture, components, data flows, and trust boundaries of the system in scope.
2. What can go wrong? — the threats, expressed as specific ways an attacker could abuse the system as described.
3. What are we going to do about it? — mitigations, ranked by how much risk they remove.
4. Did we do a good enough job? — validation that the mitigations actually address the threats identified.

That four-question structure — sometimes called the Shostack framework, after security engineer Adam Shostack, who popularized it in his 2014 book Threat Modeling: Designing for Security — underlies nearly every methodology in use today. Where methodologies differ is in how they answer questions two and three: whether threats are found by working through a fixed checklist of threat categories, by simulating an attacker’s actual behavior, by focusing specifically on privacy harms, or by mapping out attack paths as a formal tree structure. The rest of this page walks through those differences.

It’s worth separating threat modeling from two things it’s often confused with. It is not the same as a vulnerability scan or penetration test those look for flaws in something that already exists; threat modeling is frequently done before a line of code is written, working from a design or architecture diagram rather than a running system. And it’s not the same as a risk assessment in the compliance sense (a broad inventory of organizational risks) — threat modeling is scoped to a specific system, application, or product, and produces threats specific enough to design against.

Where Threat Modeling Fits in the Development Lifecycle

Threat modeling works best started early and repeated often, rather than performed once. In a typical SDLC:

• Design and architecture phase — this is where threat modeling delivers the most value per hour spent, because a threat found here changes a design decision rather than requiring rework of shipped code. Most methodologies assume this is the primary entry point.
• Pre-release / pre-deployment — a second pass, checking the as-built system against the original model, since implementation details (a third-party library, an exposed API, a shortcut taken under deadline pressure) routinely introduce threats the design-phase model didn’t anticipate.
• Ongoing, as the system changes — new features, new integrations, new deployment environments, and new attacker techniques all age a threat model. Teams practicing continuous or DevSecOps-integrated threat modeling treat the model as a living artifact updated alongside the codebase, rather than a document filed away after one review.
• Retroactively, for existing systems — a system built without a threat model can still get one; several methodologies and standards explicitly support building a threat model for a system already in production or already in the field, which matters for legacy applications and long-lived products.

The common failure mode across all four is treating threat modeling as a single gate passed once, early, and never revisited — which is also why a growing number of compliance frameworks (PCI DSS’s software-attack requirements, FDA’s medical device premarket guidance, IEC 62443-4-1’s product security requirement, among others) now expect the threat model itself to be maintained, not just produced once.

Inputs and Outputs

A threat model is only as good as what goes into it. Typical inputs include:

• Architecture and design documentation — diagrams, data flow diagrams, network topology, API specifications.
• Business context — what the system does, what data it handles, what happens if it’s compromised (financial loss, safety impact, regulatory exposure, reputational damage).
• Technology stack detail — languages, frameworks, cloud services, third-party components and dependencies.
• Threat intelligence — known attack patterns relevant to the technology stack or industry, drawn from sources like MITRE ATT&CK, CVE databases, or industry-specific threat reporting.
• Existing controls — what’s already in place, so the model identifies gaps rather than re-deriving controls that already exist.

The output, regardless of methodology, is typically some combination of:

• A decomposed model of the system — the architecture broken into components and trust boundaries, often as a diagram.
• A list of identified threats, described specifically enough to act on (not “SQL injection is possible” in the abstract, but “the login endpoint accepts unsanitized input from an unauthenticated user”).
• A risk ranking — which threats matter most, based on likelihood and impact.
• Mitigations mapped to threats, prioritized alongside the ranking.
• Documentation that a security reviewer, auditor, or new team member can pick up and understand without re-deriving the whole analysis.

Who Participates

Effective threat modeling is not a solo exercise performed by a security team in isolation. Depending on the methodology and the organization, participants typically include:

• Security engineers or architects, who often facilitate the process and bring attacker-perspective expertise.
• Software developers and engineers, who understand the actual implementation detail a design document doesn’t capture.
• System or solution architects, who own the overall design being modeled.
• Product owners or business stakeholders, who can speak to what a given threat would actually cost the business if realized — a step that risk-centric methodologies like PASTA build in explicitly, and that purely technical methodologies sometimes skip.
• Compliance or privacy officers, particularly for methodologies like LINDDUN or for systems subject to regulatory threat-modeling expectations.

The right mix shifts with what’s being modeled: a purely technical component might need only engineers and architects, while a customer-facing application handling regulated data benefits from having business and compliance stakeholders in the room from the start.

The Methodology Landscape

“Threat modeling” describes a category of practice, not one procedure. Five methodologies account for most real-world use, each built around a different way of finding and organizing threats.

STRIDE

Developed at Microsoft in the late 1990s, STRIDE organizes threats into six categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. For each component or data flow in a system diagram, a team asks which of the six threat types could apply. STRIDE is fast to learn, doesn’t require specialized tooling, and is well suited to design reviews where the goal is broad, systematic coverage of technical threat categories. Its main limitation is that it doesn’t natively rank threats by business impact — two STRIDE findings can look equally “found” even though one would cost a company nothing and the other would be catastrophic, so teams often pair STRIDE with a separate risk-scoring step.

PASTA

PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage, risk-centric methodology co-created by VerSprite CEO Tony UcedaVélez and Marco Morana, first published in the 2015 book Risk Centric Threat Modeling. The seven stages are: Define Objectives, Define Technical Scope, Application Decomposition, Threat Analysis, Vulnerability & Weakness Analysis, Attack Modeling, and Risk & Impact Analysis. Unlike STRIDE’s category checklist, PASTA starts from business objectives and works forward through simulated attacker behavior, explicitly tying every identified threat to a business-impact score before mitigations are prioritized. That makes PASTA well suited to organizations that want threat modeling output a non-technical stakeholder can act on, or that need documented, risk-ranked evidence for a compliance or audit purpose. The tradeoff is that PASTA’s seven stages take more time and more cross-functional participation than a single STRIDE session — a cost that pays off most clearly on systems where business impact varies widely between threats. VerSprite’s own delivery of PASTA is covered in depth on the PASTA Threat Modeling page.

LINDDUN

LINDDUN is a privacy-focused threat modeling methodology developed at KU Leuven, built around seven privacy threat categories: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, and Non-compliance. Where STRIDE and PASTA are primarily security-threat frameworks, LINDDUN is purpose-built for systems handling personal data, and is a natural fit for privacy-impact assessments under regulations like GDPR. Teams building systems with significant personal-data exposure often run LINDDUN alongside a security-focused methodology rather than instead of one, since the two cover different threat categories.

Attack Trees

Attack trees, formalized by security technologist Bruce Schneier in a widely cited 1999 article, represent threats as a hierarchical tree: a root node states the attacker’s overall goal (e.g., “compromise the payment system”), and child nodes break that goal into the specific sub-attacks that could achieve it, down to concrete, actionable steps. Attack trees are less a full methodology than a modeling technique — they’re frequently used inside a broader process (including within PASTA’s attack-modeling stage) rather than as a standalone end-to-end methodology. Their strength is making complex, multi-step attack paths visually explicit; their limitation is that building a thorough tree for a complex system can take considerable effort, and the technique doesn’t inherently include a business-impact ranking step.

VAST

VAST (Visual, Agile, and Simple Threat modeling) was designed specifically to scale threat modeling across large organizations running Agile and DevOps workflows, where dozens or hundreds of applications need modeling on an ongoing basis rather than a handful modeled thoroughly. VAST splits threat modeling into two distinct model types — application threat models and operational threat models — and is built to integrate with existing DevOps toolchains and ticketing systems rather than requiring a separate, standalone process. It’s a strong fit for large engineering organizations that need threat modeling embedded directly into sprint workflows at scale; smaller organizations or single-application efforts are less likely to need VAST’s specific scaling machinery.

Choosing a Methodology

No single methodology is correct for every situation. Some practical starting points: STRIDE for a fast, structured technical review during a design session; PASTA where business-impact ranking and cross-functional buy-in matter, or where a compliance framework expects documented risk-based evidence; LINDDUN where personal data and privacy harms are the primary concern; attack trees as a technique for mapping a specific, complex attack path in detail; and VAST where the real challenge is scaling threat modeling across a large, fast-moving engineering organization. Many mature security programs use more than one — for example, LINDDUN alongside STRIDE or PASTA for a system handling sensitive personal data, or attack trees nested inside a PASTA attack-modeling stage.

What is the PASTA Threat Modeling 7 Steps Framework?

Building a PASTA Threat Model That Fits Your SDLC

PASTA isn’t one-size-fits-all. Organizations running legacy waterfall processes and those running Agile sprints have both adapted PASTA’s seven stages to fit their own development timelines — treating each stage as modular, and adopting or deprioritizing specific activities based on internal capability and realistic delivery windows.

GitLab is a well-documented example: they built their own threat modeling program on top of PASTA, adapting the framework to their own engineering culture rather than applying it rigidly.

Get Expert Help With Threat Modeling

Have a specific system you need modeled? VerSprite’s threat modeling services, including Threat Modeling as a Service (TMaaS) and PASTA-based engagements, can help. Contact VerSprite to talk through what threat modeling looks like for your organization.