Threat modelling is one of the highest-leverage things a team can do, and one of the least likely to stay current. The usual lifecycle: a senior engineer runs a workshop, someone produces a diagram, a document lands in a wiki — and then the system keeps changing while the model sits frozen at the moment it was written.
Aribot — AI Threat Modelling (Immersive Demo)
More on the Ayurak AI channel.
The three reasons models go stale
They're expensive to produce
A good threat model demands scarce senior time and structured thinking. Because it's costly, it's done rarely — at design time, if you're lucky, and almost never again. The economics push it toward a one-off event rather than a living practice.
They drift the moment they're finished
Architecture is not static. A new service, a new data store, a new integration — each changes the threat surface, and none of them automatically updates the model in the wiki. Within a quarter the document describes a system that no longer exists. A model that doesn't track the architecture is describing a museum exhibit.
They live apart from the work
The threat model sits in a document. The vulnerabilities sit in an issue tracker. The architecture sits in diagrams and code. These three never talk. An engineer fixing a finding has no easy way to see which architectural threat it maps to, and a model reviewer has no easy way to see which findings already exist. The context dies at every boundary.
Teams also tend to pick one lens and stop. STRIDE is excellent for enumerating per-component threats. MITRE ATT&CK describes how real adversaries operate. Newer agentic-AI frameworks like MAESTRO cover risks the older models never anticipated. Picking only one leaves whole classes of threat unexamined — but running all of them by hand is exactly the cost that made the model a one-off in the first place.
What the gap costs
The expensive vulnerabilities are overwhelmingly architectural — decisions about trust boundaries, segmentation, and data flow that are locked in long before a scanner runs. A shared datastore reachable from two services without segmentation is invisible to code-level tools and obvious to a current threat model. When the model is stale, that class of risk goes unexamined until something exploits it. The cost of a dusty model isn't the workshop you skipped; it's the design flaw you shipped.
The fix is to make it cheap and continuous
The only durable answer is to remove the two things that kill threat models: the cost of producing them and the drift after. That means generating the model from the architecture itself, refreshing it as the system changes, and connecting each threat to the findings and controls that already exist — so the model is a live view, not a frozen artefact.
The companion piece shows how Aribot runs STRIDE, MITRE ATT&CK and MAESTRO in a single automated pass — and keeps the model current.
STRIDE, MITRE & MAESTRO in one pass