What is Threat Modeling?

Overview of Threat Modeling

Threat modeling analyzes a system’s architecture from an attacker’s perspective and produces a map from identified threats to the design weaknesses they exploit and the countermeasures that mitigate them.

A practitioner working group published the Threat Modeling Manifesto in 2020. It frames the practice through five values, among them “a culture of finding and fixing design issues over checkbox compliance” and “continuous refinement over a single delivery.”

Why Threat Modeling Matters

Boehm and Basili’s 2001 IEEE Computer article states that finding and fixing a software problem after delivery is “often 100 times more expensive” than finding and fixing it during the requirements and design phase, though the ratio falls to about 5:1 for small, noncritical systems. A payment service crossing a trust boundary warrants more scrutiny than an internal logging utility, and security reviewers use the model to locate design-level risk.

Your architects and security reviewers work from one shared architecture description with agreed trust boundaries. Reviewers record which risks the team mitigated and which it knowingly accepted; that written record is the foundation of sound risk management and gives release owners a clear basis for decisions.

When To Use Threat Modeling in the SDLC

Build the initial model in the design phase, before implementation begins. In requirements, your team names the sensitive data and trust relationships the model covers. Design is where the data flow diagram and threat enumeration happen; implementation and testing verify that the mitigations shipped.

NIST SP 800-218, the Secure Software Development Framework, states that addressing security earlier in the software development lifecycle (SDLC) takes “less effort and cost” to reach the same level of security.

Update the model for major features and for architecture or sensitive-data changes. The Manifesto’s principles call for analysis that follows “design changes in iterations that are each scoped to manageable portions of the system.”

The Threat Modeling Process: Four Core Questions

Adam Shostack codified the practice as four questions, and the Threat Modeling Manifesto uses a near-identical sequence. Most modern methodologies follow Shostack’s Four Question Framework.

1. What are we working on? Diagram the architecture, including data flows and trust boundaries.

2. What can go wrong? Enumerate threats by tracing the attack paths an adversary could take through the system and applying a framework such as STRIDE.

3. What are we going to do about it? Map each threat to a mitigation, an accepted risk, or a design change.

4. Did we do a good job? Validate that mitigations shipped and the model still matches the built system.

Data Flow Diagrams and Trust Boundaries

The data flow diagram (DFD) answers “what are we working on?” with four element types: external entities, processes, data stores, and data flows. A trust boundary marks where the trust level changes: internet to corporate network, user mode to kernel mode. Under “STRIDE per element,” every data flow is subject to tampering, information disclosure, and denial-of-service threats, and boundary-crossing flows get the most reviewer attention.

MITRE’s Center for Threat-Informed Defense publishes guidance for layering ATT&CK adversary tactics onto STRIDE, PASTA, or attack-tree models; by mapping each tactic to the trust boundaries already identified in those frameworks, teams can trace the attack paths an adversary could follow from initial access through lateral movement to their ultimate objective.

Threat Modeling Frameworks

Loren Kohnfelder and Praerit Garg introduced STRIDE at Microsoft in 1999, and both Microsoft’s Security Development Lifecycle (SDL) and OWASP use it. Its six categories each violate a security property:

• Spoofing: An attacker uses another user’s authentication information, violating authentication.
• Tampering: An attacker modifies data at rest or in transit, violating integrity.
• Repudiation: A user denies performing an action and no party can prove otherwise, violating non-repudiation.
• Information disclosure: The system exposes data to unauthorized individuals, violating confidentiality.
• Denial of service: An attacker denies service to valid users, violating availability.
• Elevation of privilege: An unprivileged user gains privileged access sufficient to compromise the system, violating authorization.

Three other frameworks cover ground STRIDE does not:

LINDDUN starts from the same DFDs, so teams run security and privacy analysis in parallel. MITRE’s Center for Threat-Informed Defense publishes guidance for layering ATT&CK framework adversary tactics onto an existing STRIDE or PASTA model, and teams use the Common Vulnerability Scoring System (CVSS) to score vulnerabilities surfaced during modeling.

Prioritizing and Mitigating Identified Threats

CVSS v4.0 scores severity from 0.0 (None) to 10.0: Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), and Critical (9.0–10.0). That score feeds directly into risk prioritization — teams address the highest scorers first and defer or accept lower-severity findings based on business impact.

For design-level threats that carry no common vulnerabilities and exposures (CVE) identifier, teams score likelihood and impact instead, which is the risk analysis step PASTA places in its final stage. The same risk prioritization logic applies: rank by combined score, then work down the list.

Deciding what to fix, defer, or accept is the core of risk management. Good risk management means the team can justify every mitigation decision against a documented score rather than intuition.

In practice, teams pair each category with a control class: stronger authentication for spoofing, integrity checks and signing for tampering, audit logging for repudiation, encryption and access control for information disclosure, rate limiting for denial of service, and least privilege for elevation of privilege.

Threat Modeling vs. Penetration Testing and Code Review

Threat modeling examines the design, penetration testing attacks the running system, and code review inspects the implementation. A penetration tester cannot flag a missing trust boundary, and a code reviewer will not catch a correctly implemented feature that grants excessive privilege. NCC Group describes threat modeling as “creating a blueprint for future penetration testing.”

Threat Modeling in DevSecOps

Teams running DevSecOps practice continuous threat modeling: re-running the model on every architecture change rather than once per release. The model lives in the same repository as your service. That keeps it current. In the SANS Institute’s 2023 DevSecOps survey, 80.3% of participants rated the combined category of threat modeling, attack surface analysis, and architecture reviews useful or very useful, moving the practice from 11th place in 2022 to 5th in 2023.

Threat modeling tools

Most teams work in one of these tools:

• OWASP Threat Dragon: Open source, supports STRIDE and LINDDUN, and auto-generates threats and mitigations from a rule engine.
• Microsoft Threat Modeling Tool: Free Windows application central to Microsoft’s SDL, with STRIDE-per-element guided analysis and Azure-specific templates.
• ThreatModeler and IriusRisk: ThreatModeler completed its acquisition of IriusRisk in December 2025, and ThreatModeler supports both products.

Organizations without in-house capacity can buy Threat Modeling as a Service (TMaaS) from VerSprite or we45.

Related concepts

Threat modeling sits alongside several complementary security practices that together span the full development lifecycle. Static application security testing (SAST) analyzes source code for vulnerabilities once implementation begins. MITRE ATT&CK can be layered onto design-focused frameworks such as STRIDE or PASTA to add a taxonomy of real-world adversary tactics and techniques those models lack. CVSS is commonly used to score and prioritize the vulnerabilities that threat modeling surfaces, helping teams decide which risks to address first.

FAQ

Teams starting out ask these most often.

What does a threat model produce?

A threat model identifies threats and maps them to design weaknesses and prioritized countermeasures.

When should threat modeling happen?

Build the first model at initial design, then update it whenever architecture, integrations, data stores, trust boundaries, or sensitive data change.

How does threat modeling differ from penetration testing?

Threat modeling works on the design; a penetration test attacks running software.

Which frameworks exist beyond STRIDE?

PASTA covers business risk, LINDDUN covers privacy, and OCTAVE covers asset-driven organizational risk, and teams layer ATT&CK and CVSS on top.

What tools do teams use for threat modeling?

Teams build most models in:

• OWASP Threat Dragon
• Microsoft Threat Modeling Tool
• ThreatModeler/IriusRisk

TMaaS is available from VerSprite or we45.

What is a data flow diagram and what is a trust boundary?

A data flow diagram maps external entities, processes, data stores, and flows, and teams mark trust boundaries with dashed lines.

How JFrog Supports Secure Development

Threat modeling works at design time: diagram, enumerate, mitigate, verify, then update the model as the architecture changes.

Turning those design-time countermeasures into enforced controls is where the JFrog Software Supply Chain Platform comes in. The JFrog Platform turns design commitments into gates the pipeline applies.

• JFrog Xray scans binaries and their transitive dependencies at any depth, including dependencies missing from manifests.
• JFrog Curation screens third-party packages before they enter your repositories.
• JFrog Advanced Security adds contextual analysis of exploitability.

To learn more about how the JFrog Platform supports your security program, start a free trial or schedule a demo.