Threat modeling in AI-era development needs better framework choices

At a glance

What this is: This is an analysis of three threat modeling frameworks, showing that STRIDE identifies threats, DREAD prioritises them, and PASTA aligns analysis to business risk.

Why it matters: It matters because IAM, NHI, and application security teams need threat modeling methods that still work when code changes quickly, privileges are distributed, and design assumptions age fast.

👉 Read Apiiro's analysis of STRIDE, DREAD, and PASTA for threat modeling

Context

Threat modeling is the practice of asking how a system could be attacked before those attack paths become exploitable weaknesses. In AI-era development, the core governance problem is not whether security teams recognise the value of early analysis, but whether their framework and workflow can keep up with continuous delivery, larger codebases, and more automated development.

For identity and access practitioners, the intersection is direct. Threat models increasingly need to account for authentication tokens, service accounts, API-driven trust boundaries, and privilege escalation paths that can be introduced long before runtime monitoring sees them. That makes framework choice a control decision, not just a methodology preference.

Key questions

Q: How should security teams choose between STRIDE, DREAD, and PASTA?

A: Use STRIDE when you need broad, repeatable threat identification, DREAD when you need to rank an existing list of threats, and PASTA when you need a business-aligned analysis of a critical system. Many teams combine STRIDE and DREAD for practicality, then reserve PASTA for high-consequence applications where attack simulation changes the remediation decision.

Q: Why do identity and privilege paths need to be in threat models?

A: Because many modern attacks do not start with code flaws alone. They move through authentication tokens, service accounts, delegated permissions, and broken trust boundaries. If those paths are absent from the model, teams miss the ways spoofing or privilege escalation can turn a design issue into a real compromise.

Q: What do teams get wrong about scoring threat severity?

A: They often treat numeric scoring as objective even when the underlying assumptions vary between reviewers. A score only becomes useful when the team agrees on what damage, exploitability, and discoverability mean in its own environment and validates the result against business impact.

Q: When should organisations use PASTA instead of lighter frameworks?

A: Use PASTA when the system is business critical, the attack path needs simulation, and executive stakeholders need risk translated into business outcomes. For smaller changes or faster-moving teams, the overhead can outweigh the benefit, so a lighter framework is usually the better fit.

Technical breakdown

STRIDE threat categories map design flaws to attack classes

STRIDE groups design-time threats into six categories: spoofing, tampering, repudiation, information disclosure, denial of service, and escalation of privilege. The framework works by mapping system components, data flows, trust boundaries, and external entities against each category, usually from a data flow diagram. Its value is breadth and repeatability, not precision scoring. That makes it useful for surfacing whole classes of weakness early in the SDLC, especially where authentication, trust boundaries, and privileged interactions are already visible in the architecture.

Practical implication: use STRIDE when you need a structured first-pass threat inventory for new designs or major changes.

DREAD adds scoring but not objective prioritisation

DREAD is a five-part scoring model built to rank threats already identified elsewhere. Damage, reproducibility, exploitability, affected users, and discoverability are each scored to produce a severity ranking. In theory, this turns qualitative threat modelling into a more defensible prioritisation exercise. In practice, the scores remain subjective, and teams often diverge on discoverability or exploitability unless they define shared assumptions. DREAD is therefore best understood as a decision support layer, not a standalone source of truth.

Practical implication: use DREAD to force explicit remediation ranking, but calibrate scoring criteria so different reviewers do not produce incompatible results.

PASTA links attack simulation to business impact

PASTA takes a seven-step, business-aligned approach that starts with objectives and scope before moving through decomposition, threat analysis, weakness analysis, attack modelling, and risk impact analysis. Its distinguishing feature is the attempt to simulate how an attacker would actually chain weaknesses into an outcome, then translate that outcome into business terms. That makes it stronger for executive reporting and high-value systems, but it also makes the method slower and more resource-intensive than STRIDE or DREAD.

Practical implication: use PASTA for the systems where a full attack path and business consequence analysis justify the extra effort.

Threat narrative

Attacker objective: The attacker wants to turn a design flaw into unauthorized access, control, or disclosure before security teams detect the path.

1. Entry begins with architectural trust assumptions that let attackers or testers reach exposed interfaces, identities, or data flows without first proving they are legitimate.
2. Escalation follows when spoofing, tampering, or broken access controls let the actor move from observation to privilege gain or control of trusted components.
3. Impact occurs when the attacker can disclose sensitive data, alter system behaviour, or expand access beyond the intended boundary.

NHI Mgmt Group analysis

Threat modeling is becoming a governance problem, not just a design exercise. STRIDE, DREAD, and PASTA were built for environments where analysis could keep pace with relatively stable system designs. AI-assisted coding and continuous deployment shorten that window, which means the quality of the framework matters less than whether it is embedded into delivery. Security teams should treat threat modeling as a control in the software supply chain, not a one-off review.

Identity and privilege paths are now central threat-model inputs. Modern application risk increasingly runs through authentication tokens, service accounts, delegated access, and API trust boundaries. That makes identity architecture part of the attack surface, especially where broken access control or privilege escalation can emerge from the way systems are connected. Practitioners should ensure threat models explicitly include human and non-human identities, not just application components.

DREAD’s weakness is not the score, it is the false confidence. A numeric ranking can make prioritisation feel objective even when underlying assumptions differ between reviewers. That is especially dangerous in large programmes where teams use the same number to justify inconsistent remediation decisions. Security leaders should use DREAD as a conversation aid, then validate it against business impact and exploit path reality.

PASTA is the most useful reminder that attack paths matter more than isolated findings. By simulating how a threat becomes an outcome, it forces teams to think in terms of chained weaknesses rather than disconnected issues. That approach aligns well with NIST CSF and broader risk governance because it links technical flaws to business consequence. Practitioners should reserve it for critical systems where that extra depth changes investment decisions.

Framework choice is now a scaling decision. STRIDE supports speed and consistency, DREAD helps with triage, and PASTA supports deeper executive alignment. The right question is not which framework is best in theory, but which combination will still function when systems change daily and the security team cannot inspect every design manually. Practitioners should pick the lightest framework that still produces defensible decisions.

What this signals

Threat modelling will increasingly need to include non-human identities as first-class assets. As application delivery accelerates, the practical gap is no longer threat taxonomy but whether identity pathways are visible enough to model. Teams that cannot trace OAuth connections, service accounts, and delegated access will struggle to produce threat models that survive real-world change.

NHI visibility debt: if a programme cannot see its machine identities, it cannot reliably model how those identities become attack paths. That is the governance gap behind many design-time blind spots, and it links directly to visibility guidance in the Top 10 NHI Issues.

Security leaders should expect more pressure to connect application threat modelling with control frameworks such as the NIST Cybersecurity Framework 2.0 and identity lifecycle governance. The organisations that do this well will move from isolated reviews to repeatable prevention across design and delivery.

For practitioners

• Embed threat modeling into delivery gates Require threat modeling at design review, major schema changes, and API boundary changes so risks are captured before code merges. Link the output to architecture review rather than treating it as a separate security ritual.
• Treat identity paths as first-class attack surfaces Map authentication tokens, service accounts, delegated access, and trust boundaries in every model, then test where spoofing or privilege escalation could occur through those paths.
• Use DREAD only after shared scoring rules exist Define what each score means for your environment, including exploitability and discoverability, so reviewers use the same assumptions when ranking threats.
• Reserve PASTA for high-consequence systems Apply the full seven-step approach to systems where business impact, compliance exposure, or resilience requirements justify the extra analysis time.

Key takeaways

• STRIDE, DREAD, and PASTA solve different problems, so the right choice depends on whether you need identification, prioritisation, or business-aligned simulation.
• Identity and privilege boundaries are now core threat-model inputs because many modern attack paths run through tokens, service accounts, and delegated access.
• Threat modeling only scales when it is embedded into delivery workflows and tied to real business impact, not treated as an occasional security exercise.

Key terms

• Threat Modeling: A structured way to identify where an application can be entered, abused, or misused before or during development. It maps trust boundaries, access points, and likely abuse cases so teams can design controls that match the way attackers and misuse actually happen.
• STRIDE: STRIDE is a threat classification framework that groups design risks into spoofing, tampering, repudiation, information disclosure, denial of service, and escalation of privilege. It helps teams systematically review system components and map each one to likely attack classes during design analysis.
• DREAD: DREAD is a threat scoring method that rates damage, reproducibility, exploitability, affected users, and discoverability. It is used to prioritise identified threats, but its results still depend on the consistency of reviewer judgment and the assumptions used in scoring.
• PASTA: PASTA is a seven-step threat modelling method that starts from business objectives and works through technical scope, attack simulation, and risk impact analysis. It is designed to connect technical vulnerabilities to operational and business consequences, especially for complex systems.

What's in the full article

Apiiro's full analysis covers the framework mechanics and comparison detail this post intentionally leaves at the strategic level:

• Step-by-step STRIDE, DREAD, and PASTA comparison guidance for design reviews and security workshops
• Practical examples of how each framework handles authentication, tampering, and privilege escalation scenarios
• Decision criteria for choosing a lighter or deeper threat modeling method based on team maturity and delivery speed
• Operational guidance on how to integrate threat modeling into engineering workflows without slowing delivery

👉 Apiiro's full post covers the framework comparison, use cases, and trade-offs in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to broader security and risk decisions across the programme.