Should you build or buy Threat Modeling Automation?
Threat modeling automation software helps security and engineering teams diagram system architecture, apply a framework like STRIDE to surface likely threats, map them to compliance requirements, and route the resulting mitigations into a ticketing system. Buyers are application security teams at organizations running a secure-development lifecycle across many engineering teams.
Run threat modeling on free tools with model-as-code in CI while the program is small; buy a platform when you need maintained libraries, compliance mapping and governance across dozens of teams, and treat LLM-drafted models as reviewed drafts, not findings.
Build it, buy it, or bridge?
When building makes sense
Running threat modeling on free tools is a real, working choice today. OWASP Threat Dragon is a Production-status project with 486,840 downloads and 110 contributors, generates threats automatically from a data-flow diagram, and supports STRIDE, LINDDUN, and several other frameworks out of the box. pytm and Threagile take the model-as-code approach further, storing models in Git and running checks in CI alongside the rest of your pipeline. For a security team of a handful of people covering a handful of engineering teams, this is a legitimate production setup, not a stopgap. What it does not give you is a maintained library of hundreds of compliance mappings or a way to enforce consistent modeling across dozens of teams without a lot of internal glue code. Build when your program is small enough that one or two people can own the content.
When buying makes sense
Buying earns its keep once a program has to scale past what one or two people can maintain by hand. ABN AMRO's own case study describes moving threat modeling from whiteboard sketches and screenshots to a self-service model on IriusRisk, spreading consistent practice across development teams that previously treated it as a niche exercise. IriusRisk and ThreatModeler sell curated threat and countermeasure libraries, compliance mappings across more than a hundred frameworks, and workflow integration that turns a diagram into tracked tickets automatically; that governance layer, not the modeling engine itself, is the actual product. ThreatModeler's 2026 acquisition of IriusRisk, and Security Compass's earlier acquisition of Devici, add some roadmap uncertainty worth asking vendors about directly. Buy when the program spans many teams and needs consistent, audit-ready evidence, and treat any AI-drafted threat model as a first draft for a person to review.
The desk read
Build-versus-buy analysis for Threat Modeling Automation is being written. In the meantime, the framework that drives every B4 call is on the B4 Index page.
Frequently asked
Are the free and open-source threat modeling tools good enough for production use?
Yes, for a program of modest size. OWASP Threat Dragon carries Production status with 486,840 downloads and 110 contributors, and generates threats automatically from a diagram using STRIDE or other frameworks. pytm and Threagile add model-as-code workflows that run in CI.
What does a paid platform add that the free tools do not?
Maintained threat and countermeasure libraries, mappings to more than a hundred compliance frameworks, and workflow integration that routes findings into ticketing systems automatically, which matters once a program spans dozens of engineering teams rather than one or two.
Can an LLM just generate the threat model for me?
It can draft one from a design document, and vendors now market this feature directly. Treat the output as a first draft a person reviews, since the underlying architecture still needs a human who understands it.
Should I worry about the ThreatModeler and IriusRisk acquisition?
It is worth asking about directly before signing a new contract. ThreatModeler acquired IriusRisk in January 2026 and the two plan to combine into ThreatModeler Nexus with phased upgrades, which adds some near-term roadmap uncertainty for existing customers of either platform.