Your Threat Model Is Lying to You: Why Modeling the Design Isn't Enough in 2026

Your Threat Model Is Lying to You: Why Modeling the Design Isn't Enough in 2026

Speakers: Farshad Abasi, Founder and CEO, Ward Security & Eureka DevSecOps

Conference: BSides SF

YouTube: https://www.youtube.com/watch?v=cCicutdGE8Q

Overview

In his compelling BSides SF talk, "Your Threat Model Is Lying to You: Why Modeling the Design Isn't Enough in 2026," Farshad Abasi challenges the prevailing wisdom in application security. Abasi, a veteran in the field, argues that traditional threat modeling, which predominantly focuses on design-time artifacts like architecture diagrams and data flow diagrams, has become fundamentally insufficient for securing modern software systems. The core premise is that design intent often diverges significantly from production reality, creating critical security blind spots that attackers readily exploit.

Abasi's presentation is a wake-up call for security professionals operating in today's fast-paced, distributed, and continuously evolving DevOps and Agile environments. He highlights how rapid delivery cycles, pervasive infrastructure drift, and increasingly deep dependency chains render static, design-centric threat models obsolete almost as soon as they are created. This talk is crucial for anyone involved in software security, from developers and architects to CISOs, as it not only dissects the root causes of this "lie" but also proposes a pragmatic, actionable framework to bridge the gap between theoretical design and operational reality.

The talk emphasizes that while current threat modeling methodologies and scanning tools are valuable, their true potential is often unrealized due to a critical missing feedback loop. Abasi demonstrates how organizations are already generating a wealth of security evidence through various scanning tools (SAST, SCA, DAST, cloud security scans) but are failing to leverage this data to inform and update their threat models. By advocating for a shift from merely logging vulnerabilities as tickets to actively using scan results to uncover and correct flawed assumptions in threat models, Abasi provides a path toward more accurate, dynamic, and ultimately more effective security posture.

Background

▶ Watch: Introduction: Your Threat Model Is Lying to You (0:00)

Farshad Abasi brings nearly three decades of experience in software development and security to this discussion, having started in the dot-com era and later pivoting to product security at HSBC in 2008. His journey mirrors the industry's evolution, from waterfall methodologies to Agile and DevOps. At HSBC, Abasi was tasked with building and scaling an AppSec team, which required him to become proficient in threat modeling, often relying on classic resources like the Microsoft threat modeling book. This hands-on experience, spanning 17 years of practicing and teaching threat modeling, underpins his critical perspective.

He notes that when he began, what was designed was generally very close to what was shipped. Threat modeling during the design phase, followed by change controls, was considered sufficient. However, the landscape dramatically shifted with the advent of Agile and DevOps. Modern software delivery is characterized by its speed, distributed nature, and constant change. Teams are deploying on demand, with some shipping 300% more code year-over-year, often driven by advancements like AI. This rapid pace means a threat model created during sprint planning can be outdated by the afternoon.

Three fundamental shifts have contributed to this growing disconnect between design and reality:

1. Delivery Speed: Organizations, particularly "elite" performers identified by Google Cloud's DORA report, deploy on demand. GitLab's survey found 69% of CISOs reported shipping two times faster, making static threat models rapidly irrelevant.
2. Infrastructure Drift: A Firefly survey revealed that only 6% of organizations have fully codified their cloud infrastructure. This leaves 94% with manually managed environments, leading to production realities that diverge significantly from declared code or design documents. This ungoverned infrastructure is invisible to pipelines and highly prone to drift.
3. Dependency Depth: A typical Java application with 20 direct dependencies can easily accumulate over 200 transitive dependencies. While a threat model might identify "dependency risk" as a category, it rarely inventories the specific 200 libraries actually running in a system, creating a "specificity gap" ripe for exploitation.

Abasi highlights that despite the widespread adoption of threat modeling (with about half the audience indicating they do it), most practitioners engage in traditional, design-focused methods, often using STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) as a classification system. Very few practice Agile or abuse case threat modeling, and almost none engage in "reverse threat modeling" – using scanner data to inform the threat model. This leads to a common pattern where threat models are created once, filed away, and never reconciled with deployed systems.

This problem is compounded by organizational challenges:

• Compliance Checkbox Mentality: Many organizations perform threat modeling primarily to satisfy compliance requirements (e.g., SOC 2, ISO 27001), rather than to inform engineering decisions. Auditors often only check if a model exists, not its accuracy.
• Lack of Feedback Loops: Even when pen tests or security scans yield valuable findings, these are often treated as isolated tickets in a backlog, never feeding back into the threat model to update assumptions. SafeCode documented these exact failures back in 2017, yet they remain prevalent.
• Resource Constraints: BSIMM consistently finds that dedicated security staff represent only about 1% of the development organization. This scarcity makes it impossible to assign security consultants to every development team, leading to the adoption of concepts like security champions, but still results in less than 10% of organizations threat modeling 90% or more of their applications.
• Structural Separation: Even in recent BSIMM reports, while AI has reshaped security priorities, there remains no explicit activity for feeding scan results back into threat models. Threat modeling falls under "threat intelligence," while security automation and scanning are under "secure SDLC touchpoints," reinforcing a harmful structural separation.

Key Findings

▶ Watch: Speaker's journey: 29 years experience, AppSec pivot (2:00)

The central and most impactful finding of Abasi's talk is that design intent is not production reality, and this fundamental disconnect causes threat models to "lie." This lie stems from the fact that most threat models are static snapshots created at the design phase, quickly becoming irrelevant in dynamic, modern software delivery environments. The talk posits that organizations are operating with a significant blind spot, where their threat models guide security decisions based on theoretical designs, while ignoring concrete evidence from live production systems.

Abasi highlights critical statistics that underscore this problem:

• 80% of real-world security exposures originate from how systems are configured and deployed, including misconfigurations, over-privileged roles, exposed storage, and architectural drift. This contrasts sharply with the mere 1% of problems attributed to code-level CVEs. While threat models can predict CWE categories (e.g., injection, access control flaws), the actual exploitable instances often manifest due to configuration and deployment issues that are difficult to anticipate at design time alone.
• Only 6% of cloud infrastructure is fully codified, meaning a vast majority (94%) is managed manually and prone to drift. If threat models rely on architecture diagrams based on Infrastructure as Code (IaC), and IaC covers so little of the actual environment, the threat model's protective scope is severely limited. Less than a third of companies continuously monitor for drift, exacerbating the problem.

The talk introduces a crucial distinction between confirmation and discovery in security findings:

• Confirmation: A vulnerability finding validates a risk that the threat model already predicted (e.g., model predicted injection risk, SAST found SQLI). This indicates an implementation gap, not a model gap.
• Discovery: A finding surfaces something the threat model missed entirely—an unmodeled component, an unknown dependency, or a trust boundary drawn incorrectly because deployment diverged from design. This is where the critical "gap" resides.

Abasi argues that the industry's failure lies not in the threat modeling methodologies themselves, nor in the capabilities of modern security scanning tools, but in a practice gap: the absence of a structured feedback loop to integrate production evidence back into the threat model. Organizations are generating immense amounts of valuable security data through SAST, SCA, DAST, and cloud scanning, but this data is predominantly treated as a backlog of tickets rather than a source of intelligence to refine and update the foundational threat model. This means that even when controls are prescribed, and tools exist to verify them, the critical question—"What does this finding tell us about what our threat model got wrong?"—is rarely asked.

Technical Deep Dive

▶ Watch: Challenging traditional threat modeling and current practices (4:00)

The technical heart of Abasi's argument lies in demonstrating how the design-reality gap manifests in real-world breaches and how existing security tools already provide the necessary evidence to bridge this gap.

The "Gap" with Numbers:

The speaker emphasizes the tangible divergence between design and production. For instance, the Firefly survey indicated that only 6% of organizations have fully codified their cloud infrastructure. This leaves 94% with manually managed environments, which are inherently prone to drift, ungoverned, and often invisible to automated pipelines. If a threat model is based on IaC-defined architecture diagrams, and that IaC only covers a fraction of the actual deployed environment, the model's protective value is severely diminished. This "invisible" 94% represents a massive attack surface that threat models, based on design, simply cannot see.

Furthermore, Abasi cites XM Cyber's finding that 80% of real-world security exposures stem from misconfigurations and deployment issues (e.g., over-compromised roles, exposed storage, drifted architecture). This is in stark contrast to only 1% of exposures attributed to code-level CVEs. While a good threat model should include risks like misconfiguration or excessive privileges and prescribe controls like least privilege or encryption at rest, the reality is that these controls are often not implemented correctly across all production resources or they drift over time. The model might say "apply least privilege," but production could have "24 to 47 Lambdas," with "three of them having admin access that nobody remembers granting."

Breaches as Case Studies:

1. Capital One Breach (2019): This incident serves as a prime example of a configuration gap. The initial entry point was a Server-Side Request Forgery (SSRF), a well-understood code vulnerability. However, what made it catastrophic was the architecture-level trust assumptions surrounding it. The EC2 instance running the Web Application Firewall (WAF) had excessive IAM privileges. Crucially, the IMDSv1 (Instance Metadata Service version 1) was accessible from that role. The attacker leveraged the SSRF to obtain temporary credentials from IMDSv1, subsequently enumerating and reading every S3 bucket in the account.

• The Model's Blind Spot: The design likely treated the WAF as a trust boundary and a security control. A deep enough threat model might have asked, "What happens if the WAF instance is compromised?" or "What can the WAF role access?" However, the model was done at a higher level, failing to account for the deployment reality where the WAF, intended as a protector, simultaneously became an attack vector due to its over-permissioned role and IMDSv1 accessibility. This was a deployment architecture problem, not a code problem, where the deployment reality diverged critically from the design assumption.

1. Log4Shell (2021): This incident illustrates a dependency gap. The vulnerability, CVE-2021-44228 (remote code execution in Log4j via JNDI), often resided deep within transitive dependencies (three to five levels deep). Developers frequently didn't explicitly choose or even know about the presence of Log4j. CrowdStrike highlighted that a major challenge during the response was visibility; organizations simply didn't know where or if they were using it.

• The Model's Blind Spot: A good threat model might prescribe "vulnerabilities in third-party dependencies" as a risk and "keep dependencies scanned and updated" as a control. Software Composition Analysis (SCA) tools (e.g., Snyk, Dependabot, OWASP Dependency Check) are designed to find such vulnerabilities by resolving the full dependency tree. However, the crisis occurred because many organizations weren't running SCA in 2021, and crucially, those that were running it treated the output as mere Jira tickets. They failed to feed these findings back into the threat model to ask: "Does this change our understanding of the attack surface? Does this reveal something the model missed about what actually got deployed?" The evidence existed, but the critical questions were not asked, and the feedback loop to the model was broken.

Leveraging Existing Data for Discovery:

Abasi argues that organizations already possess the data needed to close this gap:

• SAST (Static Application Security Testing): Finds code-level weaknesses. It can confirm predicted risks (e.g., SQLI where injection was modeled) or discover unmodeled architectural deviations (e.g., a direct service-to-service call bypassing an API gateway, revealing a data flow not in the design).
• SCA (Software Composition Analysis): Finds dependencies, especially transitive ones, that teams didn't know were present (e.g., Log4j). This provides evidence of whether the "scan and update dependencies" control actually covers the real dependency tree.
• DAST (Dynamic Application Security Testing): Reveals runtime behaviors, unmodeled endpoints, or accidental deployment artifacts (e.g., a debug endpoint left in production). DAST provides evidence that a predicted possibility (like an accidental artifact) has materialized.
• IaC and Cloud Scanning: These tools find drift, misconfigurations, and trust boundary issues that don't match architecture diagrams, echoing the Capital One scenario. They provide evidence for whether "least privilege" or other cloud security controls are truly in place.

In essence, every build and deploy generates this critical data, but it's largely wasted as isolated tickets. The technical deep dive reveals that the problem isn't a lack of tools or methodologies, but a practice gap—a failure to interpret scan results as intelligence that can evolve and correct the threat model's understanding of the system's actual attack surface.

Demo / Proof of Concept

▶ Watch: Key argument: Design intent is not production reality (4:50)

While Farshad Abasi's talk doesn't feature a live code demo or a traditional software proof-of-concept, it effectively "demos" a six-step workflow that acts as a practical extension to existing threat modeling practices. This workflow is the core solution proposed to bridge the gap between design intent and production reality, requiring no new tools or budget, only a change in practice.

The speaker emphasizes that this is not a replacement for design-time threat modeling but an essential post-build step. The "proof of concept" is the logical demonstration of how this workflow, using readily available data, can uncover critical blind spots.

The Six-Step Workflow:

1. Export Your Most Recent Scan Findings:

• Action: Gather results from all security scanning tools in use—SAST, SCA, DAST, IAST, cloud infrastructure scanning (e.g., Prowler, Cloud Custodian). If only one type of scan is performed, start there.
• Rationale: The tools themselves don't matter as much as the practice of utilizing their output. This step consolidates the "evidence" from production.

1. Map Each Finding to the Component in Your Architecture:

• Action: For every vulnerability or misconfiguration found, identify the specific architectural component (e.g., "Payment Processing Service," "User Authentication Module," "S3 Bucket for logs") it relates to.
• Rationale: This forces a crucial connection between raw scan data and the system's architectural model. Many organizations lack this mapping, as scan teams and architecture teams often operate in silos.

1. For Each Finding, Ask: "Was This Risk Modeled in Our Threat Model for This Component?" (Yes/No):

• Action: Compare the detected risk against the existing threat model for that specific component.
• Rationale: This step differentiates between confirmation (model predicted it, testing found it – an implementation gap) and discovery (model missed it entirely – a model gap). If the answer is "Yes," the model was correct, and the issue is an implementation failure; log a ticket and fix the code. If "No," proceed to the next step.

1. If the Answer is "No," Ask: "What Assumption Did the Model Make That This Finding Contradicts?"

• Action: Investigate why the threat model failed to predict this risk.
• Rationale: This crucial analytical step identifies the root cause of the model's inaccuracy. Was a trust boundary drawn incorrectly? Was there an unmodeled component or a data flow that only exists in deployment (e.g., an accidental direct service-to-service call bypassing a gateway)? Did the model assume visibility into dependencies that didn't exist?

1. Update Your Threat Model:

• Action: Based on the insights from Step 4, modify the threat model. Add newly discovered threats, fix broken assumptions, incorporate previously unmodeled components or data flows.
• Rationale: This closes the feedback loop, ensuring the threat model evolves and becomes a more accurate reflection of the actual system in production.

1. Prioritize Structural Misses:

• Action: Not all discoveries are equal. Prioritize updates that address structural gaps (e.g., a wrong trust boundary, a missing component class) over one-off code errors.
• Rationale: Structural misses indicate systemic blind spots that likely affect multiple components or applications, offering a higher return on investment for remediation and model improvement.

Concrete Example (Jackson Databind CVE):

Abasi illustrates this with a scenario involving a Jackson Databind CVE (a deserialization vulnerability) found by an SCA tool in a transitive dependency of an ORM used by a "payment processing service."

• Step 1: SCA report exported.
• Step 2: Finding mapped to the "payment processing service" component.
• Step 3: Question: "Was deserialization risk in a transitive ORM dependency modeled?" The model might have covered general deserialization risk, but not for an unmanaged, transitive library. So, the answer is "No."
• Step 4: Assumption broken: "The model assumed the team had visibility into all dependencies." The trust boundary was implicitly drawn around direct imports, making transitive ones invisible.
• Step 5: Model updated: "Add transitive dependency attack surface as a threat to the payment component."
• Step 6: Prioritize: This is a structural problem, not a one-off bug. If one component has unmodeled transitive dependencies, others likely do, indicating an organizational blind spot.

This workflow can be implemented using simple tools like a spreadsheet or an issue tracker. Abasi suggests fitting it into existing ceremonies like backlog refinement, pull request reviews, or release readiness. He also highlights that current industry frameworks (BSIMM, OWASP SAMM, NIST SSDF) reinforce the separation of threat modeling and testing, further underscoring the need for this explicit reconciliation step.

Defensive Implications

▶ Watch: Three critical changes: speed, drift, dependency depth (5:50)

The insights from Farshad Abasi's talk carry profound defensive implications for organizations grappling with modern software security challenges. The primary directive for defenders is to actively establish and maintain a feedback loop between operational security evidence and threat models. This means moving beyond a static, design-time view of security and embracing a dynamic, evidence-driven approach.

Here are the key defensive implications:

1. Integrate Scan Results into Threat Model Updates: The most critical action is to implement the proposed six-step workflow. This involves systematically analyzing findings from SAST, SCA, DAST, IAST, and cloud security scanning tools not just as tickets for remediation, but as intelligence to validate, correct, and evolve the existing threat model. Defenders must shift their mindset from merely identifying vulnerabilities to understanding what these vulnerabilities reveal about the accuracy of their underlying security assumptions.

1. Prioritize "Discovery" Over Mere "Confirmation": While confirming predicted risks is valuable, defenders should train their teams to actively seek "discovery" moments. These are instances where scan findings highlight risks or architectural elements (unmodeled components, unknown data flows, incorrect trust boundaries) that the original threat model completely missed. Prioritizing the investigation and remediation of these structural gaps will yield a higher security posture improvement, as they often represent systemic weaknesses rather than isolated bugs.

1. Regular and Frequent Threat Model Reconciliation: The traditional annual review of threat models, as even suggested by some frameworks like OWASP SAMM, is woefully inadequate for high-velocity DevOps environments. Defenders must advocate for more frequent reconciliation, potentially on a per-sprint or per-release basis. The two-week pilot proposed by Abasi is an excellent starting point to demonstrate value and build organizational buy-in.

1. Rethink Trust Boundaries and Attack Vectors: The Capital One breach example underscores the need to critically examine components previously considered solely as "security controls" (like a WAF). Defenders must threat model these controls as potential attack vectors themselves, asking "What happens if this control is compromised?" and "What privileges does it have?" This leads to more robust security architecture and stricter adherence to least privilege principles, especially for infrastructure components.

1. Enhance Visibility into Dependencies and Infrastructure Drift: The Log4Shell and infrastructure drift examples highlight the necessity of deep visibility. Defenders must ensure comprehensive Software Bill of Materials (SBOMs) are generated and actively used to track all direct and transitive dependencies. Similarly, robust continuous monitoring for infrastructure drift is essential to identify manual changes and ensure that the deployed environment aligns with codified configurations.

1. Foster Cross-Functional Collaboration: The observed silos between threat modeling teams, architecture teams, and security testing teams must be broken down. Defenders need to champion collaboration, ensuring that architects understand the implications of scan findings, and security testers understand the assumptions embedded in threat models. Security champions within development teams can play a crucial role in facilitating this communication and integrating the workflow directly into development practices.

1. Educate Management on Model Freshness and Coverage: To secure necessary resources and buy-in, defenders should use metrics such as "gaps discovered," "model freshness," "coverage delta," and "structural versus one-off ratio." These metrics can effectively communicate the value of ongoing threat model reconciliation and demonstrate the tangible improvement in understanding and addressing the organization's true attack surface.

By implementing these defensive strategies, organizations can transform their threat models from static, potentially misleading documents into living, evolving artifacts that accurately reflect the complex and dynamic reality of their production systems, thereby significantly reducing their exposure to modern threats.

Key Takeaways

• Design-time threat models are insufficient for modern software delivery: The rapid pace of Agile and DevOps, coupled with infrastructure drift and deep dependency chains, renders static threat models quickly obsolete and prone to "lying" about an application's true security posture.
• Production reality often diverges significantly from design intent: The critical gap exists because what is designed (and threat modeled) rarely perfectly matches what is actually built and deployed, leading to critical blind spots attackers exploit.
• 80% of real-world security exposures stem from misconfigurations and deployment issues: This far outweighs code-level CVEs (1%), highlighting that the problem is often in how systems are configured and operated, rather than solely in the code itself.
• A critical feedback loop from security scans to threat models is missing: Organizations often treat SAST, SCA, DAST, and cloud scan findings as isolated tickets rather than using them to update and refine the underlying threat model's understanding of the system.
• The proposed six-step workflow offers a practical solution without new tools: By systematically exporting scan findings, mapping them to components, asking if risks were modeled, identifying contradictory assumptions, updating the model, and prioritizing structural gaps, organizations can bridge the design-reality gap using existing resources.
• Prioritize "structural gaps" over one-off code errors: Discoveries that reveal incorrect trust boundaries, unmodeled components, or unknown data flows represent systemic issues that warrant higher priority for threat model updates and broader organizational learning.

About the Speaker(s)

Farshad Abasi is a highly experienced and respected figure in the cybersecurity and software development communities. He serves as the Founder and Chief Executive Officer for two companies: Ward Security, a services firm, and Eureka DevSecOps, a product company, both dedicated to helping software developers build more secure software.

With an impressive career spanning approximately 29 years, Abasi began building software during the dot-com era, having earned a computer science degree and worked for prominent companies like Intel and Motorola. In 2008, he pivoted into product security, joining HSBC, where he spent nine years building and scaling an AppSec team globally. This experience provided him with extensive, hands-on knowledge in threat modeling, which he has been teaching and practicing for 17 years.

Beyond his corporate roles, Farshad is deeply involved in the community. He is the President of B-Sides Vancouver and leads the OWASP Vancouver chapter. Notably, he is also a co-author of the OWASP Secure Pipeline Verification Standard (SPVS), a crucial project addressing the increasing attacks on software delivery pipelines. His diverse background, from a software engineer learning hard lessons to an AppSec leader and community advocate, provides a rich foundation for his insights into the evolving challenges of application security.