Automated Threat Modelling: STRIDE in CI

Q: Why does traditional threat modelling fail to keep up with modern development?

Because it produces a document at a single moment while the system it describes changes every day afterwards. A team books a room, draws a data-flow diagram, brainstorms threats with STRIDE, exports a PDF, and files it on a shared drive — where it becomes archaeology within one sprint. By the time an incident or an auditor asks what the team assumed about a particular trust boundary, the diagram shows services that were since merged, deleted, or added, and queues that no longer exist. The practice of enumerating threats against a data-flow diagram is sound; what is broken is the artefact lifecycle. The threat model ages out of sync with the code precisely because it lives beside the code, maintained by a separate human cadence of workshops, instead of inside the repository where it is regenerated by the same pipeline that builds and tests the code. The fix is not a better workshop or a bigger tool; it is moving the model into version control and executing it in continuous integration so that it changes when the architecture changes and fails the build when a change introduces a threat nobody accepted.

Q: What is threat modelling as code?

Threat modelling as code means the diagram and its associated threats are a version-controlled artefact in the repository — diffable in a pull request and executed by continuous integration — rather than a picture a person maintains by hand. There are three levels that are not equivalent. The first is a workshop plus a PDF: cheap to start, stale in a sprint, and useless as regulatory evidence. The second is diagram-as-code, where a JSON or YAML diagram (for example an OWASP Threat Dragon model or a drawio file committed next to the code) is reviewed in pull requests; this gives real version control but still relies on a human keeping the diagram in sync with reality by discipline. The third is model-as-code, where a Python or YAML description of assets, data flows, and trust boundaries (using tools such as OWASP pytm or Threagile) generates both the data-flow diagram and a ranked threat list on every run; this has the highest authoring cost and the greatest payoff, because the analysis re-runs automatically and the model can be gated in CI. The important caveat is that none of these levels makes threats appear automatically — automation re-runs a human’s analysis against a changed system and reports what moved.

Q: How can STRIDE be automated in a CI pipeline?

STRIDE is automatable because its six categories — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege — are a per-element mnemonic: each threat category attaches to specific kinds of nodes in a data-flow diagram, and a pipeline knows what kind of thing each node is. The mapping turns the mnemonic into machine-checkable proxies. Spoofing hits processes and external entities, so the check is that every process declares an authentication mechanism. Tampering and information disclosure hit data flows and stores, so boundary-crossing flows must declare integrity and TLS and stores must declare write authorization and data sensitivity. Repudiation hits processes, so state-changing actions must map to an audit-log event. Denial of service hits public-facing processes, which must declare a rate limit or quota. Elevation of privilege hits trust boundaries and processes, so authorization decisions must route through a central point rather than being scattered. When a change to the model adds or moves an element, the pipeline mechanically raises the STRIDE categories that element can suffer and checks whether the corresponding control is declared, failing the build if a new boundary-crossing risk lacks an accepted mitigation.

Q: What does automated threat modelling with STRIDE miss?

It catches the threats that follow structurally from the diagram and misses everything that depends on business logic and intent. STRIDE-per-element will reliably tell you that a new public-facing data flow lacks a rate limit, that a store crossing a trust boundary is not encrypted, or that a new process has no declared authentication — the class of architectural drift that a mnemonic bound to element types can enumerate. It will never tell you that your refund endpoint allows a user to refund the same order twice, that a discount can be stacked in a way finance did not intend, or that a sequence of individually authorised actions composes into an abuse. Those are design and logic flaws that no per-element mnemonic contains, and detecting them still requires human adversarial thinking and design review. The correct framing is that automated threat modelling is a regression net for architectural drift, not a replacement for the creative part of security analysis. Teams that oversell it as complete coverage will rightly lose trust in it the first time it misses an obvious logic abuse, so it should be positioned as the mechanical floor that frees human review to concentrate on intent.

Q: How should the CI gate be designed so developers do not disable it?

By gating on the diff rather than the absolute risk list, making acceptances owned code, and keeping the check fast. A mature system accumulates hundreds of known and accepted risks; failing every pull request on all of them turns the build permanently red and the gate is switched off within a week. Instead the pipeline should fail only on new risks that cross a trust boundary and lack an explicit acceptance, a comparison that runs in a few hundred milliseconds and therefore belongs on the pull request rather than in a nightly job. Every suppressed or accepted risk should live in a tracked file with a rationale and a named owner and be reviewed like any other change, because an accepted-risks file that only grows and that nobody revisits is how a threat model becomes a graveyard of ignored warnings. Finally the model itself must be forced to track reality: model updates should be tied to the same review that touches infrastructure-as-code, and the declared data flows should be periodically reconciled against real network policy so that the pipeline is analysing the system that exists rather than a beautiful description of one that was decommissioned months ago.

Q: Which tools support threat modelling as code?

The open-source landscape spans the three levels of maturity. For diagram-as-code, OWASP Threat Dragon stores threat models as JSON that can be committed alongside code and reviewed in pull requests, and it will suggest STRIDE threats per element. For model-as-code, OWASP pytm lets you describe a system as Python objects — actors, servers, datastores, dataflows, and boundaries — and generates data-flow and sequence diagrams plus a threat report, which makes it straightforward to run inside continuous integration. Threagile takes a declarative YAML model of assets, data flows, and trust boundaries and produces a ranked risk report with data-flow diagrams, and is designed to run as a container in a pipeline. Microsoft’s Threat Modeling Tool documents the canonical per-element STRIDE methodology that underpins the automatable mapping, though it is more workshop-oriented than pipeline-native. Commercial platforms such as IriusRisk add rule libraries and governance. The tool is the easy part of the decision; the hard part is agreeing what constitutes a trust boundary in your architecture and maintaining the vocabulary, and choosing a tool before that agreement exists is a common way to waste the investment.

Q: How does automated threat modelling relate to regulatory requirements like the Cyber Resilience Act?

Regulators have shifted from accepting a point-in-time document to expecting security analysis as a continuous engineering capability, and automated threat modelling is one of the most direct ways to produce that evidence. The EU Cyber Resilience Act places product-security obligations on manufacturers of products with digital elements, including demonstrating that security is considered throughout the lifecycle, and CISA’s Secure by Design initiative asks vendors to make secure design a default engineering practice rather than a bolt-on. A threat model that is committed to the repository, regenerated on every pull request, and gated in continuous integration produces exactly the artefact these frameworks are looking for: a living, timestamped record that a specific change was analysed for new threats and that any new risk was either mitigated or explicitly accepted by a named owner. That is far stronger evidence than a PDF from a workshop whose whiteboard was wiped, because it demonstrates the analysis is a property of the delivery process rather than a periodic ceremony, and it reconciles to the system that actually shipped.

Q: What is the first practical step toward continuous threat modelling?

Commit a diagram-as-code threat model for your single most critical service this sprint and require its review whenever that service changes. Concretely, that means creating an OWASP Threat Dragon (or equivalent) model that captures the service’s processes, data stores, external entities, data flows, and trust boundaries, storing it in the repository next to the code, and adding a lightweight rule that a pull request touching that service must also update or acknowledge the model. This is roughly a day of work and it is the foothold for everything above it: once the model is in version control and reviewed, you can graduate to generating it from a model-as-code description, then to gating the build on new boundary-crossing risks, and finally to reconciling the declared model against real network policy. The diagnostic that tells you that you are still at the beginning is simple: if your only threat model is a PDF from a workshop whose whiteboard has since been wiped, you are at the ceremony stage regardless of how thorough that session was, and committing one diagram to the repository is the move that changes it.