Threat Modeling Insider – July 2026

Written by Jordan Hardy

Threat Modeling Insider Newsletter

54th Edition – July 2026

Welcome!

Welcome to this month’s edition of Threat Modeling Insider!

In this issue, Stanley Harris from Katilyst, argues that organizations should measure whether threat modeling actually improves security, rather than simply counting threat models or identified threats.

Next, on the Toreon Blog, Asma Oualmakran highlights that AI can meaningfully accelerate every phase of the DICE framework. But when the system you’re threat modeling is an AI system, the stakes double.

There’s plenty of other actionable insight ahead, so settle in and let’s get started!

Read our previous newsletters
Threat Modeling Insider edition

Welcome!

Welcome to this month’s edition of Threat Modeling Insider! In this edition,

In this issue, Stanley Harris from Katilyst, argues that organizations should measure whether threat modeling actually improves security, rather than simply counting threat models or identified threats.

Next, on the Toreon Blog, Asma Oualmakran highlights that AI can meaningfully accelerate every phase of the DICE framework. But when the system you’re threat modeling is an AI system, the stakes double.

There’s plenty of other actionable insight ahead, so settle in and let’s get started!

Read our previous newsletters

In this edition

Guest Article
Beyond the Badges and Bots: Real Metrics for Champion-Led, AI-Assisted Threat Modeling

Toreon Blog
Meta Threat Modeling: Using AI to Threat Model Your AI System

Curated content
NIST Mathematical Proof Supports Transition to a Continuous-Monitor-and-Update Security Model for AI Systems

Curated Content
Soatok’s Informal Guide to Threat Models

Tips & tricks
Pair every threat scenario with both a short-term mitigation and a long-term strategic recommendation

Training update
An update on our training sessions.

Guest Article

Beyond the Badges and Bots:

Real Metrics for Champion-Led, AI-Assisted Threat Modeling

Written by Stanley Harris

During Katilyst’s joint webinar with Toreon this past April, an interesting question came into the chat: “We’ve spun up a Security Champions program, and they are starting to lead threat modeling sessions, but how do we prove to leadership that this is actually working?”

It’s the ultimate scaling hurdle. When a central AppSec team invests time, budget, and energy into training developers to own threat modeling, the business eventually expects a receipt.

Historically, our industry has relied heavily on lagging and vanity metrics to justify these programs. We count what is easy to see, not what is effective. If your threat modeling program is still measured by:

  • The Threat Model Count: “We completed 50 threat models this quarter.”
  • The Threat Volume: “We identified 400 STRIDE-based threats.”
  • Portfolio Coverage: “85% of our tier-1 applications have a Data Flow Diagram (DFD) or PDF attached to them.”

…then you are measuring activity, not security. A beautifully detailed, 30-page PDF threat model that lives on a Confluence page and never changes a single line of code is a failure. It is “compliance theater” disguised as “secure by design.”

To prove real impact, threat modeling practitioners must shift their focus from lagging activity metrics to operational engineering telemetry.

Three Core Telemetries for Champion Autonomy

Before we even look at the tools that developers use for threat modeling, we must measure how effectively they are scaling the threat modeling mindset. If your security team still has to sit in on every single session, your program hasn’t scaled, you’ve just added an extra meeting to the developer’s calendar.

Here are the three fundamental metrics that track real program scaling:

1. The Autonomy Ratio (Champion vs. Central AppSec Facilitation)

The primary goal of a champion program is to decentralize security expertise.

  • What it measures: The percentage of threat modeling sessions initiated, facilitated, and completed entirely by Security Champions and their product teams, without active intervention from the central security team.
  • Why it matters: This is your true indicator of self-sufficiency. A healthy scaling program should show a steady upward trajectory in champion-led sessions over a 6-to-12-month period. Central AppSec should transition from being the facilitators of threat modeling to the escalation path for highly complex architectural anomalies.

2. The Flaw-to-Vulnerability Ratio (The "Catching It Early" Index)

A design flaw is a mistake made on the digital whiteboard (e.g., missing an authentication boundary). A vulnerability is a mistake made in the code (e.g., a SQL injection). Threat modeling is designed to catch flaws before they become vulnerabilities.

  • What it measures: The ratio of structural security flaws identified during champion-led threat modeling sessions versus implementation vulnerabilities discovered later in the lifecycle (via SAST, DAST, penetration testing, or bug bounties).
  • Why it matters: If your champions are threat modeling effectively, you should see a measurable drop in late-stage, architecture-level findings. If your penetration tests are still turning up massive architectural blind spots, your threat modeling sessions are likely just checklist exercises. This metric proves the economic value of the program: catching a flaw during design costs a fraction of fixing a vulnerability in production.

3. The Guardrail Conversion Rate

As Amir Kavousian pointed out in a recent issue of this newsletter, a threat model finding that lives only as text in a Confluence page is where value goes to die. Whiteboard sessions must directly influence engineering guardrails.

  • What it measures: The percentage of threat model findings that are successfully converted into automated, testable engineering controls, such as custom linter rules or Open Policy Agent (OPA) infrastructure-as-code policies.
  • Why it matters: Champions know the local CI/CD pipelines better than anyone. This metric tracks whether your champions are successfully closing the “enforcement gap.” When a threat model finding triggers an automated policy that blocks a bad build before code is merged, your champion has created a durable, permanent security control.

The AI Threat Modeling Boom (Scaling Accelerator or Automated Noise?)

The temptation to solve the threat modeling scaling problem by throwing Generative AI at it is incredibly strong. Why spend months training champions to threat model when an LLM can spit out a model in 30 seconds?

But as Vikramaditya Narayan brilliantly articulated at the OWASP 25th Anniversary Virtual Conference in his talk on “Noise vs. Signal: The Central Paradox of LLMs in Threat Modeling,” indiscriminate use of AI creates a massive trap. When asked to generate threats, LLMs produce excessive, non-reproducible noise that overwhelms developers.

If your AI-driven threat modeling is measured purely by “number of threat models generated,” you will bury your engineering teams in alert fatigue.

However, AI can be a massive superpower for your Security Champions if it is positioned as an assistive copilot rather than an automated pilot. It can draft initial DFDs, suggest common attack paths, and help a champion overcome the “blank canvas” syndrome.

To ensure AI is actually accelerating your champions instead of drowning them in noise, you must track these two AI-specific metrics:

1. The AI Threat Acceptance Rate (The Signal-to-Noise Index)

If your AI-driven tool generates 100 threats, but your champion team only acts on five of them, the tool is a distraction, not an accelerator.

  • What it measures: The percentage of AI-generated threats or mitigations that a human champion and their team actually accept, refine, and convert into backlog tickets or automated code gates.
  • Why it matters: A low acceptance rate indicates that your AI prompts or specialized expert models are generating “explainability theater” or hallucinated edge cases. A high acceptance rate (e.g., >70%) proves that your AI assistant is dialed into your specific tech stack and is serving up highly contextual, high-fidelity security insights that developers actually respect.

2. AI-Assisted Lead-to-Enforce Time (The Velocity Accelerator)

The ultimate promise of AI is speed. But we shouldn’t just measure the speed of writing the threat model, we must measure the speed of securing the system.

  • What it measures: The average time (hours or days) it takes a team to go from identifying a threat to having an active enforcement control (e.g., a policy gate or security test) running in CI/CD when utilizing AI context and code-generation templates, versus doing it manually.
  • Why it matters: AI shouldn’t just list threats; it should help champions draft the actual policy-as-code configurations and integration test cases needed to mitigate them. If your lead-to-enforce time drops significantly, your AI is acting as a true engineering force multiplier.

Conclusion: Culture Follows Telemetry

At its core, threat modeling is not an administrative tax we pay to ship software; it is a fundamental engineering craft.

If we continue to measure our programs using legacy, activity-based metrics, we will inevitably trigger Goodhart’s Law. Developers and architects will quickly learn how to game the system, churning out hundreds of low-fidelity, bot-generated threats just to satisfy a quarterly dashboard, while the underlying code remains as vulnerable as ever.

By shifting our telemetry toward autonomy, prevention, and automated enforcement, we change the very nature of the conversation. Security stops behaving like a bureaucratic gating function and starts operating as a distributed engineering discipline.

The next time you review your threat modeling metrics, remember: a threat model isn’t finished when the Data Flow Diagram is saved to a folder. It is finished when the system’s architecture actively defends itself against the very threats you mapped out.

Let’s stop measuring the paperwork, and start measuring the guardrails.

Learn to integrate AI into your threat modeling process.

Browse Trainings

Handpicked for you

Meta Threat Modeling: Using AI to Threat Model Your AI System

The Scenario

Your team has just shipped an internal LLM-powered customer support chatbot. It takes employee questions, queries a knowledge base via a retrieval-augmented generation (RAG) pipeline, and returns answers. It connects to your CRM. It has access to customer records. And it’s live in production.

Now someone in the room asks: “Has anyone threat modeled this?”

Silence.

Then, almost inevitably: “Can we just use the AI to help us threat model it?”

It’s a fair question. And increasingly, the answer is yes, provided you understand exactly what you’re signing up for.

Read the blog


Curated Content

NIST Mathematical Proof Supports Transition to a Continuous-Monitor-and-Update Security Model for AI Systems

A new mathematical proof by NIST scientist Apostol Vassilev, inspired by Kurt Gödel’s incompleteness theorems, argues that no finite set of AI guardrails can be universally robust against all adaptive adversarial prompts. This means attackers will always have the potential to find prompts that bypass an AI system’s safeguards, creating risks such as cyberattacks, data breaches, and other misuse. While the proof does not provide attackers with specific exploits, it highlights the need for organizations to continuously search for vulnerabilities rather than assuming a one-time security fix is sufficient. Vassilev recommends ongoing red-team testing, continuous guardrail updates, and operational resilience to limit damage and recover quickly when attacks succeed. The goal is not perfect security, but making the cost and difficulty of discovering and exploiting new weaknesses high enough to deter most attackers.

Soatok’s Informal Guide to Threat Models

Soatok presents threat modeling as an informal, intuition-first practice that can be applied during design without requiring a formal methodology. A useful threat model should address seven areas: assets, attackers, attacks, mitigations, relationships between assets, explicit assumptions, and deliberately unaddressed threats. The importance of assumptions is highlighted through the Invisible Salamanders attack, where a seemingly harmless change undermined a key cryptographic assumption. He also critiques Matrix’s threat model as incomplete and outdated, while noting that it is still better than Signal having no comparable model. For practitioners, the key takeaway is to document assumptions and explicitly define what will not be fixed, while using a four-part risk taxonomy—prevented by design, mitigated, addressable, and open—to improve threat model reports.

Read more
Read more

Handpicked for you

Meta Threat Modeling: Using AI to Threat Model Your AI System

The Scenario

Your team has just shipped an internal LLM-powered customer support chatbot. It takes employee questions, queries a knowledge base via a retrieval-augmented generation (RAG) pipeline, and returns answers. It connects to your CRM. It has access to customer records. And it’s live in production.

Now someone in the room asks: “Has anyone threat modeled this?”

Silence.

Then, almost inevitably: “Can we just use the AI to help us threat model it?”

It’s a fair question. And increasingly, the answer is yes, provided you understand exactly what you’re signing up for.

Read the blog


Curated Content

NIST Mathematical Proof Supports Transition to a Continuous-Monitor-and-Update Security Model for AI Systems

A new mathematical proof by NIST scientist Apostol Vassilev, inspired by Kurt Gödel’s incompleteness theorems, argues that no finite set of AI guardrails can be universally robust against all adaptive adversarial prompts. This means attackers will always have the potential to find prompts that bypass an AI system’s safeguards, creating risks such as cyberattacks, data breaches, and other misuse. While the proof does not provide attackers with specific exploits, it highlights the need for organizations to continuously search for vulnerabilities rather than assuming a one-time security fix is sufficient. Vassilev recommends ongoing red-team testing, continuous guardrail updates, and operational resilience to limit damage and recover quickly when attacks succeed. The goal is not perfect security, but making the cost and difficulty of discovering and exploiting new weaknesses high enough to deter most attackers.

Read more

Soatok’s Informal Guide to Threat Models

Soatok presents threat modeling as an informal, intuition-first practice that can be applied during design without requiring a formal methodology. A useful threat model should address seven areas: assets, attackers, attacks, mitigations, relationships between assets, explicit assumptions, and deliberately unaddressed threats. The importance of assumptions is highlighted through the Invisible Salamanders attack, where a seemingly harmless change undermined a key cryptographic assumption. He also critiques Matrix’s threat model as incomplete and outdated, while noting that it is still better than Signal having no comparable model. For practitioners, the key takeaway is to document assumptions and explicitly define what will not be fixed, while using a four-part risk taxonomy—prevented by design, mitigated, addressable, and open—to improve threat model reports.


Read more

TIPS & TRICKS

Pair every threat scenario

with both a short-term mitigation and a long-term strategic recommendation — separating the quick fix from the deeper architectural change keeps the output useful to both engineers and leadership.

Go to channel

Book a seat in our upcoming trainings & events

Our trainings & events for 2026

3-Day Training: AI Whiteboard Hacking aka Hands-on Threat Modeling Training, in-person, OWASP Global AppSec EU, Vienna Austria

22-24 June 2026

Threat Modeling Practitioner training, hybrid online, hosted by DPI, US Cohort

June 2026

AI Whiteboard Hacking aka Hands-on Threat Modeling Training, TROOPERS, Heidelberg

22-23 June 2026

Book your spot
Book your spot
Book your spot

Threat Modeling Practitioner training, hybrid online, hosted by DPI, Europe Cohort

September 2026

2 Day Training: Beyond Whiteboard Hacking: Embracing AI-Assisted Threat Modeling, in-person, OWASP Global AppSec USA, San Francisco

3-4 November 2026

Book your spot
Book your spot
Book your spot

Book a seat in our upcoming trainings & events

Our trainings & events for 2026

3-Day Training: AI Whiteboard Hacking aka Hands-on Threat Modeling Training, in-person, OWASP Global AppSec EU, Vienna Austria

22-24 June 2026

Book your spot

Threat Modeling Practitioner training, hybrid online, hosted by DPI, US Cohort

June 2026

Book your spot

AI Whiteboard Hacking aka Hands-on Threat Modeling Training, TROOPERS, Heidelberg

22-23 June 2026

Book your spot

Threat Modeling Practitioner training, hybrid online, hosted by DPI, Europe Cohort

September 2026

Book your spot

2 Day Training: Beyond Whiteboard Hacking: Embracing AI-Assisted Threat Modeling, in-person, OWASP Global AppSec USA, San Francisco

3-4 November 2026

Book your spot

Threat Modeling Practitioner training, hybrid online, hosted by DPI, Europe Cohort

September 2026

Book your spot

Upcoming Events/Webinars

Webinar – Threat Modeling in the Age of Mythos:
What Threat Modelers Need to Do Differently
June 30 | 8 AM – 8:45 AM (EDT), Webinar together with QA

Join Toreon and our partner QA for a timely discussion on how AI-enabled security capabilities, including Anthropic’s Mythos, are changing the way organizations approach application security, product security, and secure-by-design practices.

Register
QA Webinar Thumbnail 1

Conference – ThreatModCon Vienna
26 – 27 June | Meliá Vienna

Gather with the world’s leading security architects and engineers in the heart of Vienna. Join us for a full day of uncompromising, deeply technical focus.

More info
6940113a52ee678cb72563df TMC2026 PIR Teal White scaled

Start typing and press Enter to search

Shopping Cart