Written by Jordan Hardy

Threat Modeling Insider Newsletter

53rd Edition – May 2026

Welcome!

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

In this issue, Amir Kavousian from DevArmor explains why threat modelers need to focus less on static documents and more on code.

He breaks down how policies, rules, tests, and fitness functions can make threat models truly live within the systems they describe.

Next over on the Toreon Blog, Sebastien Deleersnyder expands on the proposed ENISA draft for a Security-by-Design playbook, sharing key insights from our OWASP community input.

We also have plenty of other actionable insights for you, including a core threat modeling lesson from BIML, the story behind a $10,000 iPhone heist, and a practical tip on how to better target your threat models.

Settle in and let’s get started!

Welcome!

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

In this issue, Amir Kavousian from DevArmor explains why threat modelers need to focus less on static documents and more on code.

He breaks down how policies, rules, tests, and fitness functions can make threat models truly live within the systems they describe.

Next over on the Toreon Blog, Sebastien Deleersnyder expands on the proposed ENISA draft for a Security-by-Design playbook, sharing key insights from our OWASP community input.

Settle in and let’s get started!

In this edition

Guest Article
From findings to guardrails: Closing the threat model enforcement gap

Toreon Blog
ENISA’s secure by design playbook: Good start, hard questions

Curated content
No security meter for AI

Curated Content
How easy is it to steal $10,000 from a locked phone?

Tips & tricks
Consider realistic attacker personas

Training update
An update on our training sessions.

Guest Article

From Findings to Guardrails:

Closing the Threat Model Enforcement Gap

Written by Amir Kavousian

What Is The Enforcement Gap

Here is a scene most security practitioners will recognize: a cross-functional team spends two hours in a room with a whiteboard. They map data flows, identify trust boundaries, brainstorm threats using STRIDE, and walk out with a sense of accomplishment. The resulting threat model (a PDF, a Confluence page, maybe an export from a tool) gets filed somewhere reasonable. And then nothing happens.

The threats identified don’t become work tickets with acceptance criteria. The mitigations discussed don’t become policy gates in CI/CD. The architectural constraints agreed upon don’t become linter rules that gate a bad build. Six months later, a penetration test discovers the exact vulnerability the team identified on that whiteboard.

This is what we call “the enforcement gap”: the space between producing a threat model and operationalizing it as guardrails that live in developer workflows. And in my experience building security tooling for engineering teams, it is where the vast majority of threat modeling value is lost.

Why the Gap Exists

The enforcement gap is essentially a systems design problem. Three structural forces keep threat model outputs from becoming enforceable controls:

Abstraction mismatch.
Threat models speak in the language of risk: “An attacker could exploit insufficient input validation on the API gateway to achieve privilege escalation.” Developers need implementation-level specificity: “All endpoints in /api/v2/admin/* must validate JWT claims against the RBAC policy before processing requests.” The translation between these two levels of abstraction is manual, error-prone, and rarely prioritized.
No feedback loop.
A threat model is typically a point-in-time artifact. The system it describes evolves continuously with new endpoints, new data stores, and new integrations. Without a mechanism to detect drift between the threat model and the live system, mitigations that were once adequate become irrelevant, and new attack surfaces emerge unnoticed.
Wrong handoff point.
Threat models are often handed off as documents to development teams who are already deep in implementation. By the time a developer reads “consider rate-limiting this endpoint,” the endpoint has been in production. The output arrives too late to influence design and too early to inform a specific pull request.

What "Enforceable" Actually Means

When I say enforceable, I don’t mean “written down more clearly.” I mean threat model findings that are translated into automated controls that prevent non-compliant code from reaching production. Specifically:

Generation guardrails that enforce the mitigation plan the threat model defined at code generation time
Policy gates that block a merge if a security requirement isn’t met
Architecture fitness functions that detect structural drift from the threat model’s assumptions
Security tests derived directly from identified threats, running on every commit as integration test, penetration test, and later on as bug bounty scope

The goal is to make it harder to violate the threat model than to comply with it. Not through bureaucracy, but through automation. This is the spirit of “secure-by-design” and “secure-by-default”.

A Practical Framework: Threat-to-Guardrail Pipeline

Over the past two years, I’ve been working with security teams to close this gap. The pattern that works is a pipeline that transforms threat model outputs into enforceable artifacts at each stage of the SDLC.

Stage 1: Structured Threat Outputs

The first requirement is that your threat model produces structured, machine-readable outputs, not just prose. Each identified threat should have:

A unique identifier (for traceability)
The component or trust boundary it applies to
The specific security property at risk (confidentiality, integrity, availability, etc.)
One or more mitigations, expressed as testable requirements

This is where most processes break down immediately. If your threat model output is a paragraph describing a risk in natural language, there is no automated system that can act on it. Structured output is the bridge.

Stage 2: Mitigation-to-Policy Translation

Once you have structured mitigations, the next step is translating them into policies that your CI/CD system can evaluate. This is where Policy-as-Code frameworks like Open Policy Agent (OPA) become essential.

Consider a concrete example. Your threat model identifies: “The application stores PII in the user-profile service database. An insider threat could exfiltrate this data if encryption at rest is not enforced.”

The structured mitigation becomes: “All databases in the user-profile namespace must have encryption at rest enabled.”

The OPA policy becomes:

package infrastructure.database

deny[msg] {

input.resource.type == “aws_rds_instance”

input.resource.labels.namespace == “user-profile”

not input.resource.config.storage_encrypted

msg := “TM-042: Database in user-profile namespace must have encryption at rest (threat: insider data exfiltration)”

}



Notice the TM-042 reference: it traces directly back to the threat model finding. When this gate fires in a pull request, the developer sees exactly what they need to do (“encryption required”), but they also see why, linked to the specific threat.

Stage 3: Architecture Fitness Functions

Some threat model assumptions are structural: “The payment service must never directly access the user database” or “All external API calls must route through the API gateway.” These are architectural invariants.

Architecture fitness functions encode these as automated tests. Tools like ArchUnit (Java), dependency-cruiser (JavaScript), or custom linter rules can enforce these controls on every commit:

// dependency-cruiser rule derived from threat model boundary TM-017

{

name: “payment-service-isolation”,

severity: “error”,

comment: “TM-017: Payment service must not directly access user-db (threat: lateral movement after payment service compromise)”,

from: { path: “^src/services/payment” },

to: { path: “^src/services/user/db”, severity: “error” }

}



When a developer inadvertently introduces a direct database import in the payment service, the build fails because a specific threat model boundary has been violated.

Stage 4: Threat-Derived Security Tests

Every threat in your model implies a test case. “An attacker could bypass authentication by manipulating the session token” implies a test that attempts exactly that. These are more than just traditional unit tests; they’re abuse cases encoded as automated tests.

The most effective pattern I’ve seen is generating test scaffolds directly from the threat model. These tests can loosely follow threat categories, although that is not a requirement:

Spoofing threats → authentication bypass tests
Tampering threats → input validation and integrity tests
Repudiation threats → audit logging verification tests
Information Disclosure threats → data leakage boundary tests
Denial of Service threats → rate limiting and resource exhaustion tests
Elevation of Privilege threats → authorization boundary tests

The true value starts to be realized when these tests become part of the CI pipeline, running on every pull request and raising an alert if a mitigation control is violated.

Stage 5: Continuous Reconciliation

The final piece is a mechanism to detect when the live system has drifted from the threat model’s assumptions. This includes:

Automated architecture discovery that compares actual service dependencies against the threat model’s data flow diagram
New surface detection that flags new endpoints, new data stores, or new integrations that weren’t covered in the last threat model
Mitigation regression alerts that fire when a previously-passing security test starts failing

This creates the feedback loop that keeps the threat model alive as a living set of constraints that the system continuously validates against.

A Real-World Example

Let me share a concrete case. A fintech team I worked with had produced a thorough STRIDE-based threat model for their payment processing system. Among the findings: “An attacker who compromises the notification service could pivot to access payment transaction data through a shared database connection pool.”

In the old world, this would live as a line item in a triage spreadsheet. Maybe someone would eventually create a Jira ticket.

Instead, the team:

Created an OPA policy that denied any infrastructure-as-code change granting the notification service’s IAM role access to the payments database
Added a dependency-cruiser rule preventing code in the notification service from importing payment data models
Wrote an integration test that verified the notification service could not establish a connection to the payment database, even with valid network access
Set up drift detection that would alert if a new IAM policy was attached to the notification service role

Three months later, during a sprint to add payment confirmation notifications, a developer naturally reached for a direct database query to the payments table. The build failed at three different points: the dependency rule, the OPA policy (when they tried to update the IAM role), and the integration test. Each failure message referenced the original threat model finding, explaining why this boundary existed.

The developer understood the threat, redesigned the feature to use an event-driven approach, and the payment service boundary remained intact.

Getting Started: The 80/20 Path

You don’t need to implement all five stages at once. Here’s the progression I recommend:

Step 1: Structure your outputs.
Pick your most recent threat model and restructure its findings into a machine-readable format. JSON, YAML, even a well-structured spreadsheet. Each finding needs an ID, component, security property, and testable mitigation.

Step 2: Pick your top 3 threats and write policies.
Choose the three findings with the highest risk and clearest mitigation path. Write OPA policies, linter rules, or CI checks that enforce them. Run them in “warn” mode first.

Step 3: Promote policies to blocking.
Once you have tuned out false positives, flip the warnings to hard blocks. Your first enforced threat model findings are now live.

Step 4: Build the feedback loop.
Add drift detection for covered components. Expand coverage to more findings. Iterate.

The Cultural Shift

The technical implementation is the easy part. The harder shift is cultural: moving threat modeling from a “security team activity that produces documents” to a “collaborative process that produces enforceable code.”

When developers see their builds fail with a message like TM-042: Database must have encryption at rest (threat: insider data exfiltration), they start to internalize the threat model. It’s no longer an abstract document, but it’s a constraint they interact with daily. Over time, they start designing with those constraints in mind from the start.

This is the real win. Not that you caught a violation, but that the next developer doesn’t create one in the first place because the guardrails made the threat model’s reasoning visible and immediate.

Conclusion

The threat modeling community has made enormous progress on the production side: better methodologies, better tools, better training. But until we close the enforcement gap, we’re leaving most of that value on the table.

The path forward is not more documents or data flow diagrams. It’s fewer documents and more code: policies, rules, tests, and fitness functions that make threat models live in the systems they describe. The whiteboard session is where understanding begins. The CI/CD pipeline is where it becomes durable.

About the Author:

Amir Kavousian is the founder and CEO of DevArmor, an AI-native platform that helps security teams create threat models and turn them into enforceable guardrails. He can be reached on LinkedIn or at amir@devarmor.com.

Learn to integrate AI into your threat modeling process.

Handpicked for you

ENISA’s Secure by Design Playbook: Good Start, Hard Questions

ENISA deserves credit.

Its Security by Design and Default Playbook tackles a problem many product teams already face: how to translate high-level secure-by-design expectations into practical engineering work. The playbook provides SMEs and manufacturers with concrete actions, release gates, and evidence expectations rather than another abstract security framework. That matters under the Cyber Resilience Act, where “we thought about security” will not be enough. ENISA’s draft maps secure-by-design and secure-by-default principles to lifecycle activities, practical playbooks, and CRA-related evidence expectations.

The question is not whether the playbook is useful. It is.

The harder question is whether teams will use it to improve product security, or whether it becomes another checklist that product teams complete without changing design decisions. That distinction is where threat modeling matters.

Curated Content

NO SECURITY METER FOR AI

Your AI scored 92% secure — please enjoy this beautifully calibrated false sense of safety.” Relevant for our readers because this BIML paper lands squarely on a core threat modeling lesson: security is not a leaderboard score, a benchmark result, or a shiny “AI safety” badge. It argues that AI security is an emergent system property, so teams need to model architecture, data provenance, agent behavior, assurance processes, and failure modes rather than trusting black-box benchmark scores as a proxy for real resilience.

How easy is it to steal $10,000 from a locked phone?

The $10,000 “Express” Leak – In a sleek collaboration with MKBHD, Veritasium demonstrates a “nerdy David Blaine” stunt siphoning $10,000 from a locked iPhone by exploiting Apple’s Express Transit mode. For threat modelers, it’s a masterclass in trust boundary erosion: a feature designed for $2 subway fares was tricked into authorizing a high-value heist because the design assumed “transit” always meant “low-risk.” It’s a reminder that when we bridge a gap for convenience, we often build the exact path an attacker needs to bypass our strongest authentication.

Handpicked for you

ENISA’s Secure by Design Playbook: Good Start, Hard Questions

Curated Content

NO SECURITY METER FOR AI

How easy is it to steal $10,000 from a locked phone?

TIPS & TRICKS

Consider realistic attacker personas

Model threats from the perspective of realistic attacker personas relevant for your system. The same system has different risks depending on whether the attacker is an insider, external cybercriminal, competitor, hacktivist, or nation-state actor.

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

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 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

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

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

September 2026

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.

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.

Threat Modeling Insider Newsletter

Welcome!

Welcome!

In this edition

From Findings to Guardrails:

Closing the Threat Model Enforcement Gap

What Is The Enforcement Gap

Why the Gap Exists

What "Enforceable" Actually Means

A Practical Framework: Threat-to-Guardrail Pipeline

Stage 1: Structured Threat Outputs

Stage 2: Mitigation-to-Policy Translation

Stage 3: Architecture Fitness Functions

Stage 4: Threat-Derived Security Tests

Stage 5: Continuous Reconciliation

A Real-World Example

Getting Started: The 80/20 Path

The Cultural Shift

Conclusion

About the Author:

Learn to integrate AI into your threat modeling process.

Handpicked for you

ENISA’s Secure by Design Playbook: Good Start, Hard Questions

Curated Content

NO SECURITY METER FOR AI

How easy is it to steal $10,000 from a locked phone?

Handpicked for you

ENISA’s Secure by Design Playbook: Good Start, Hard Questions​

Curated Content

NO SECURITY METER FOR AI

How easy is it to steal $10,000 from a locked phone?

TIPS & TRICKS

Consider realistic attacker personas

Book a seat in our upcoming trainings & events

Our trainings & events for 2026

Book a seat in our upcoming trainings & events

Our trainings & events for 2026

Upcoming Events/Webinars

ENISA’s Secure by Design Playbook: Good Start, Hard Questions