What is threat modeling?
Threat modeling is a structured, proactive approach to identifying potential security threats in a system by analyzing it from an attacker's perspective before vulnerabilities can be exploited. Verizon's 2025 DBIR highlights exploitation as a significant initial access vector, reinforcing why proactive threat identification matters before attackers discover vulnerabilities first. This matters because it shifts security from reactive firefighting to deliberate design, catching architectural flaws when they're cheap to fix rather than after a breach, which IBM reports can cost millions on average globally in its Cost of a Data Breach research.
Every threat modeling methodology builds on four foundational questions, originally articulated in OWASP's threat modeling guidance:
What are we building? Define the scope and identify assets worth protecting.
What can go wrong? Systematically identify threats that could compromise those assets.
What are we going to do about it? Determine mitigations for each significant threat.
Did we do a good enough job? Validate that controls actually address the identified risks.
The output of threat modeling is understanding, not documentation. A perfectly formatted diagram that nobody references provides zero security value. The real benefit comes from the structured conversations that force developers, architects, and security practitioners to think through attack surfaces and trust boundaries together.
Guided Tour
See Wiz Defend in Action
What are the benefits of threat modeling?
Finds design flaws before code is written: Catching architectural vulnerabilities during design costs far less than discovering them in production. Threat modeling surfaces issues like missing authentication, inadequate encryption, or excessive trust relationships that are expensive to retrofit later.
Creates shared understanding across teams: Threat modeling sessions bring developers, security practitioners, and operations together to align on what matters. This shared understanding reduces friction during security reviews because teams have already discussed and agreed on security requirements.
Prioritizes security investment: Organizations can focus limited security resources on the highest-risk areas rather than spreading effort across low-impact issues. Understanding which threats matter most enables informed decisions about where to invest in controls, monitoring, and testing.
Improves incident response readiness: When you have modeled attack paths, you can prepare detection and response procedures before incidents occur. Threat models inform incident response playbooks, helping teams respond faster when modeled scenarios materialize.
Supports compliance and audit requirements: Threat modeling documentation demonstrates security thinking and risk-based decision making to auditors and regulators. Many compliance frameworks explicitly or implicitly require threat analysis as part of secure development practices.
How does threat modeling work?
While specific frameworks and methodologies vary, the core threat modeling process remains consistent. You can apply this workflow at different scales: a single microservice, an entire application, a Kubernetes cluster, or a complete cloud environment.
Step 1: Define scope and identify assets
Before analyzing threats, you need to answer: what are we protecting? Asset identification includes data stores, services, credentials, API keys, and infrastructure components. In cloud environments, this also means understanding which workloads access sensitive data and which identities have privileged permissions.
Trust boundaries separate different security zones. External users sit outside one boundary; internal services operate within another; privileged systems and sensitive data stores require additional separation. Mapping these boundaries reveals where attackers must cross from untrusted to trusted contexts.
Complete visibility matters here. You cannot threat model what you cannot see. In cloud environments, manual inventory is always incomplete because infrastructure changes constantly through IaC deployments and auto-scaling. In practice, teams need an always-current inventory that includes identity relationships (IAM roles, service accounts, workload identities) and data sensitivity classifications, not just a list of hosts and IP addresses. Automated discovery becomes essential for accurate threat modeling in environments where a Kubernetes deployment might create dozens of new pods in minutes.
Step 2: Decompose the system
Create an architectural representation showing how data moves between components. Data flow diagrams (DFDs) typically illustrate processes, data stores, external entities, and the flows connecting them. This decomposition identifies entry points like APIs, user interfaces, and network listeners, plus dependencies including databases, external services, and identity providers.
Cloud-native architectures look different from traditional systems. Instead of static servers with known IP addresses, you're modeling containers, serverless functions, managed services, and identity relationships that may change dynamically. With Kubernetes widely adopted in production environments (as reflected in CNCF's annual cloud-native survey), a deployment might spin up new pods continuously, each inheriting permissions and network access from its service account configuration.
Step 3: Identify threats
Apply a framework like STRIDE to systematically enumerate what can go wrong at each component and data flow. Structured enumeration beats ad-hoc brainstorming because frameworks ensure you consider threat categories you might otherwise miss.
Threats differ across layers:
Compute threats: Container escape, remote code execution, malicious image deployment
Identity threats: Privilege escalation, credential theft, token hijacking
Data threats: Exfiltration, tampering, unauthorized access to sensitive stores
Network threats: Traffic interception, lateral movement, DNS poisoning
Step 4: Analyze and prioritize
Not all threats are equal. A vulnerability on an internet-exposed workload with access to sensitive data and admin privileges is fundamentally different from the same vulnerability on an isolated test instance with no data access. This risk-based prioritization helps teams focus on what matters most by surfacing exploitable paths to sensitive assets rather than treating all vulnerabilities equally. Context determines which threats actually matter.
Attack path analysis connects individual threats into chains showing realistic exploitation scenarios. Instead of treating each vulnerability in isolation, you trace how an attacker could chain together an exposed API, a misconfigured IAM role, and access to a sensitive data store into a complete compromise. A useful output isn't "100 threats listed"; it's a small queue of exploitable paths tied to owners and validated exposure, transforming theoretical risks into prioritized action items that teams can actually address.
Step 5: Mitigate and validate
Define countermeasures for prioritized threats. Preventive controls like input validation and least privilege stop attacks before they succeed. Detective controls including monitoring and alerting catch attacks in progress. Corrective controls such as incident response procedures limit damage when prevention fails.
Verification matters as much as planning. Test that mitigations actually work through security testing, code review, and configuration validation. For residual risk that cannot be fully prevented, connect to detection capabilities that identify exploitation attempts in real time.
Common threat modeling frameworks
Multiple frameworks exist for different purposes and contexts. Experienced practitioners often combine elements from several frameworks based on what fits their specific situation. Frameworks are thinking tools that provide structure, not rigid checklists to follow blindly.
STRIDE
STRIDE is Microsoft's framework organizing threats into six categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. Each category maps to a security property: authentication defeats spoofing, integrity defeats tampering, and so on.
STRIDE works particularly well for application threat modeling where you're analyzing specific components and data flows. Walk through each element in your data flow diagram and ask which STRIDE categories apply.
PASTA
PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage risk-centric methodology connecting technical threats to business impact. Its stages progress from business context through technical analysis to risk treatment.
Use PASTA when you need to align threat modeling with business objectives and risk appetite, particularly for organizations with mature risk management programs. The business framing makes PASTA useful for communicating with non-technical stakeholders.
LINDDUN
LINDDUN addresses privacy threats: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, and Non-compliance. Security-focused frameworks often miss privacy concerns that LINDDUN surfaces explicitly.
Apply LINDDUN when privacy is a primary concern, such as GDPR compliance, healthcare applications, or systems processing personal data.
Attack trees
Attack trees are hierarchical representations decomposing an attacker's goal into sub-goals and specific attack steps. They excel at detailed analysis of high-value attack scenarios and communicating complex attack chains visually.
Combine attack trees with other frameworks: use STRIDE for initial enumeration, then build attack trees for the most critical threats requiring deeper analysis.
Which framework should you use?
Select frameworks based on context: STRIDE for application-level analysis, PASTA for business-aligned programs, LINDDUN for privacy concerns, attack trees for deep-dive analysis. Hybrid approaches often work best, using STRIDE for initial enumeration combined with PASTA's business context.
The best framework is the one your team will actually use consistently. A simple approach applied regularly beats a sophisticated methodology gathering dust.
Wiz’s Approach to threat modeling
Traditional threat modeling produces static diagrams that drift from reality within days. Wiz replaces that cycle with continuous, graph-based cloud threat modeling.
Live infrastructure model, not stale diagrams
The Wiz Security Graph maps every cloud resource, identity, workload, and data store, along with the relationships between them. As infrastructure and permissions change, attack paths are recalculated automatically. No agents are required for broad cloud visibility, while the Wiz Sensor adds runtime depth where needed.Attack paths, not isolated risks
Rather than cataloging individual vulnerabilities, the Security Graph identifies toxic combinations. These are specific chains of exposure, privilege, and data access that create exploitable paths. A vulnerable container becomes critical when it is internet exposed, over permissioned, and connected to sensitive data. This mirrors how attackers operate and how Wiz prioritizes.Identity centric threat modeling
Because identity is the cloud control plane, Wiz models lateral movement, privilege escalation, and cross account access. This shows how an attacker could move through your environment and what they could ultimately reach.Attacker relevant intelligence
Wiz Research maintains a cloud threat intelligence database mapped to MITRE ATT&CK. Findings are enriched with real world attacker techniques, helping teams understand how active threat patterns intersect with their environment.Code to cloud traceability
When the graph surfaces a risky configuration, Wiz traces it back to its source, whether a Terraform template, container image, or CI CD pipeline. Teams can remediate root causes instead of repeatedly patching symptoms in production.Runtime validation with Wiz Defend
Wiz Defend detects exploitation attempts along modeled attack paths and enriches detections with full graph context. Threat models inform what to monitor. Runtime signals confirm whether mitigations hold.
Get a demo to see how Wiz turns threat modeling into a continuous, context driven practice aligned with how your cloud actually runs.
Guided Tour