Threat model drift: when the diagram stops matching the deployment

A threat model drawn at architecture review is a snapshot - accurate the day it was made, and wrong by the next sprint. Services appear, network paths shift, IAM roles accumulate, and bucket policies change without ceremony. The diagram stays on the wiki. The attacker works from the real deployment. That gap is threat model drift, and a quarterly workshop does not close it - a continuous IaC parse does.

01Why diagrams rot faster than code

Code is the system; the diagram describes an intent. A Terraform pull request that opens a new security group rule changes the actual attack surface in the time it takes to merge. A data flow diagram in a wiki takes a human to discover the change, redraw the affected trust boundaries, re-evaluate the new flows under STRIDE, and reach team consensus - by which point several more changes have landed. Even teams that run threat modeling seriously cannot keep a manual diagram current at modern deploy cadence. The result is not a diagram that is slightly stale - it is a diagram that has never seen the last six weeks of commits.

02IaC as the live source of threat-model truth

The alternative to trusting a human-maintained diagram is parsing the infrastructure definitions that actually describe the deployment. Terraform, CloudFormation, Kubernetes manifests, Helm charts and docker-compose files are typed, diffable and version-controlled. Every field is a fact with a file and line number - not an intent expressed in a diagramming tool that nobody is required to update before merging. Parsing them on each commit turns the threat model into a continuous projection of the real deployment rather than a snapshot of an earlier intent.

resource "aws_security_group_rule" "admin_public_ingress" {
  type        = "ingress"
  from_port   = 443
  to_port     = 443
  protocol    = "tcp"
  cidr_blocks = ["0.0.0.0/0"]  # internet-zone actor reaches admin component
}

resource "aws_s3_bucket_acl" "audit_logs" {
  bucket = "audit-logs-prod"
  acl    = "public-read"  # internet actor reads data asset without auth
}

# Parser output (new commit vs previous state):
+ trust_edge: internet --> admin-service  port=443  zone_crossing=yes
+ trust_edge: internet --> s3/audit-logs-prod  auth=none  sensitivity=high

Each resource maps to a typed component in the threat model: a security group rule becomes a trust-boundary edge with source zone, destination zone and port set; a public-read S3 ACL becomes an internet-accessible data store with a sensitivity label derived from the resource name and applied tags. When that edge was absent in the previous commit, it is a new trust-boundary crossing - and new crossings produce new threat entries automatically, anchored to the IaC line that created them. The diagram is a rendered output of that parse, not its input.

03What undetected drift enables

The impact of a drifted threat model is not just a stale picture. It is a real attack surface carrying no threat entries, no mitigations assigned and no owner who knows it exists. An admin service opened to the public internet to speed up a hotfix that was never reverted is a target with no defense-in-depth review behind it. The threat model did not fail to mitigate the threat - it never looked at that component. DAST finds the open port; the IaC parse gives it the context: this crossing was not present before this commit, and nothing in the model accounts for it.

04Closing drift continuously

The cadence question has a direct answer: the threat model must update at least as fast as the infrastructure it describes. That is achievable only if the update is automatic. Parsing IaC on each commit, computing the delta against the previous model state, and projecting new trust-boundary crossings into threat entries removes the human bottleneck. Security engineers review the new entries - a bounded set scoped to what changed in this commit - rather than trying to reverse-engineer what drifted across a month of merges. A threat model that is always current is also one that can be gated: a commit that introduces a critical-rated, unmitigated trust-boundary crossing fails the build in the same way that a DAST critical finding does.

DAST provides the runtime layer that confirms structural findings. A new internet-reachable endpoint identified by IaC parsing is immediately probed: authentication challenge check, parameter discovery, injection surface scan against a benign marker. The threat entry is grounded in both the structural fact (IaC says this port is open to the internet) and the runtime confirmation (DAST reached the service and received a substantive response). Neither source alone is sufficient: IaC can describe a port that nothing listens on; DAST alone finds the live endpoint but cannot tell you whether the architect intended it to be public or whether any mitigations exist. The combination is the proof.

Threat model drift is not a process failure - it is a structural one. A process that requires humans to keep a diagram synchronized with a system that changes on every merge will always fall behind. The fix is treating IaC as the threat model: every resource a typed component, every security group rule a trust-boundary edge, every commit a re-evaluation of the surface. The diagram becomes an output of that parse, not the input to a quarterly meeting - and an attacker who knows what is actually deployed never had the advantage of working from a drawing that is six weeks old.