AI
Why Design-Time Threat Models Fail
Three changes make design-time threat models obsolete. Delivery speed: DORA’s 2024 report classifies elite teams as deploying on demand. GitLab’s survey of 5,300 people found 69% of CISOs ship two times faster. Infrastructure drift: Firefly surveyed 350 companies; only 6% had fully codified cloud infrastructure. The other 94% have manually managed portions. Dependency depth: a typical Java app with 20 direct dependencies can have 200+ transitive ones. Threat models inventory risk categories, not the specific 200 libraries running in production.
The Feedback Loop That Doesn’t Exist
88% of practitioners use STRIDE. 74% say diagrams are mandatory. Yet 52% have no management reporting. Only 25% have a dashboard. Most threat models are created at project kickoff, filed in Confluence or SharePoint, and never reopened. Teams treat scan results as Jira tickets, not as evidence to update the model. BSIMM’s latest study of 111 organizations and 91,000 applications found no activity connecting scan results back to threat models. The structural separation between threat intelligence and SSDLC touchpoints persists.
Two Breaches That Exploited the Gap
Capital One’s 2019 breach used a boring SSRF. The WAF instance had an IAM role with excessive privileges. AWS metadata service (IMDSv1) was accessible. The attacker got temporary credentials and read every S3 bucket. The threat model treated the WAF as a trust boundary, not an attack vector. Log4Shell in 2021 exploited a transitive dependency three to five levels deep. Organizations with SBOMs responded in hours; those without took two weeks. Both breaches exploited the gap between design assumptions and production reality.
Your Pipeline Already Has the Evidence
SAST, SCA, DAST, and cloud scanning already generate evidence. SAST finds code-level weaknesses. Sometimes it confirms a modeled risk: the model predicted injection at component X, SAST found SQLi. That is confirmation. Other times it discovers something unmodeled: a developer added a direct service-to-service call bypassing the API gateway. That is discovery. SCA finds dependencies the team did not know about. DAST reveals runtime endpoints like a debug endpoint deployed to production. Cloud scanning finds drift and misconfigurations. The evidence exists. The question is not being asked.
A Six-Step Workflow to Close the Loop
No new tools needed. Export scan findings. Map each finding to a component in the architecture. Ask: was this risk modeled for this component? If yes, confirmation. If no, discovery. Identify the broken assumption: wrong trust boundary, missing component, unmodeled data flow. Update the threat model. Prioritize structural gaps over one-off bugs. A wrong trust boundary is systemic. Run a two-week pilot: pick one production application, run the six steps, document gaps, share results. Count gaps discovered, model freshness, coverage delta, structural versus one-off ratio.
Q&A
Why should the threat model handle this instead of config management or dependency management? The threat model’s purpose is to understand how attackers can attack the system; it must reflect production reality, and scan results are the evidence to keep it accurate. ▶ 45:01
Notable Quotes
Design intent is not production reality, right? Farshad Abasi · ▶ 5:07
The model says, “Hey, apply least privilege, right?” But production has 24 to 47 Lambdas and three of them have admin access that nobody remembers granting. Farshad Abasi · ▶ 21:45
The EC2 instance functioned as both a security control and attack vector simultaneously. Farshad Abasi · ▶ 24:02
The evidence existed. The question wasn’t being asked. Farshad Abasi · ▶ 28:16
Key Takeaways
- Design-time threat models miss production drift, misconfiguration, and transitive dependencies.
- Scan results are evidence; treat them as model updates, not just tickets.
- A six-step workflow can reconcile findings with threat models in two weeks with no new tools.
About the Speaker(s)
Farshad Abasi is the Founder and CEO of Forward Security and Eureka DevSecOps, bringing over 29 years of industry experience to the forefront of cybersecurity innovation. His professional journey includes key technical roles at Intel and Motorola, evolving into senior security positions.