Threat modeling is a playbook, not a product.
The security industry has spent twenty years selling threat modeling as a workshop, a tool category, a compliance checkbox. It's none of those things. It's a task the AI already in your PR flow can do on every merge. We just shipped it as one YAML file.
The workshop that dies in a drawer
Every regulated org has done threat modeling at least once. Someone booked two days on the calendar, a security architect ran STRIDE on a whiteboard, the output landed in a PDF. Six months later the architecture drifted, three services got added, two APIs got refactored, and the threat model was fiction.
Auditors still asked for it. So most teams either produced the stale PDF, or ran the workshop again the week before the audit. Neither is governance. Both are theater.
What threat modeling actually is
Threat modeling is the reasoning step where you look at a design and ask, for each STRIDE category: what could go wrong here? Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
Vulnerability scanners can't do this. A scanner reads code and matches known bad patterns. It has no concept of what the code is trying to do, or what would be catastrophic if it did the wrong thing. It can find the stringeval(). It cannot tell you that your new endpoint accepts a userId query parameter and returns billing data without checking ownership.
The reasoning is the hard part. And it's exactly what the current class of AI models is good at.
How we shipped it
One YAML file: apps/api/playbooks/threat-modeler.yaml. It hooks into the existing Conduct runtime. No new module, no new database table, no new UI page. Six blocks:
- recall_prior — read the last threat model for this repo
- plan — single turn: identify what changed in the PR and which STRIDE categories are in scope
- draft_stride — agentic turn: enumerate concrete threats tied to specific code paths
- file_findings — POST each threat to
/security-findings - comment_pr — post the markdown threat model as a PR comment
- record — save the threat model so the next PR can skip duplicates
Findings flow into the same table as scanner output. They show up in the same /secure/findings UI. They roll into the same MTTR metrics. If severity is high, they chain into security-autopilot-fix which drafts a PR with the mitigation. Full loop, no glue code.
Why this is not a product
CognitivTrust, IriusRisk, ThreatModeler, and a handful of newer entrants are selling threat modeling as a dedicated product with its own dashboard, its own workflow, its own login. The pitch is legitimate. The design is wrong for how modern teams actually work.
Threat modeling is not a separate activity from the rest of security. It is one participant in the loop that already includes scanning, remediation, and audit. Splitting it into its own tool is the same category error as splitting dependency scanning into a separate product from SAST — which is why Snyk, Semgrep, and every SCA vendor eventually converged into ASPM platforms.
If the AI in your PR flow can draft a threat model as easily as it can suggest a variable rename, it should. And the output should land in the same place every other security finding lands.
What it costs
One playbook run per PR. Sonnet 4.6 is enough — STRIDE is structured output, not reasoning at the edge of the model. In our own repo, a run takes 30-60 seconds and costs under 5 cents. Compliance evidence for SOC 2 CC7.3, PCI DSS 12.3.1, and ISO 27001 A.14.2.1 falls out for free.
If you want threat modeling that stays current, isn't a separate product, and files into your existing security loop, the playbook is in the registry under threat-modeler. Install it, point it at a repo, watch STRIDE run on your next PR.