Drift Source

Drift source is the identity or tool responsible for a Terraform drift event. That source may be a human operator, a remote team member, a developer, or an automated system acting outside the Terraform path. Identifying it helps teams move from detection to root cause and remediation.

Expanded Definition

In Terraform, a drift source is the identity or tool that introduced a configuration change outside the expected Terraform workflow. That source can be a human operator using the console, a developer applying a hotfix, a remote team member making an emergency change, or an automation system that mutated infrastructure without the same review path. The term is narrower than drift itself: drift describes the state mismatch, while drift source explains who or what created it and therefore where accountability begins.

This distinction matters because modern infrastructure often crosses multiple control planes, and a drift event can originate in places that are invisible to the IaC repository. Guidance across vendors is still evolving on how to label automated versus human-caused drift, but the operational goal is consistent: tie the state change back to an actor, an action, and a timestamp. That is the foundation for remediation, access review, and prevention. NIST’s NIST Cybersecurity Framework 2.0 reinforces this need to trace changes to accountable processes rather than treating every mismatch as a purely technical defect. The most common misapplication is blaming Terraform itself, which occurs when teams confuse a detected state difference with the identity or tool that actually made the change.

Examples and Use Cases

Implementing drift-source attribution rigorously often introduces extra investigative overhead, requiring organisations to weigh faster detection against the cost of correlating logs, session data, and change records.

• A platform engineer manually edits a security group in the cloud console to restore access during an incident, and Terraform later flags the deviation. The drift source is the engineer, not Terraform, and the follow-up should include a controlled review of the exception path.
• A CI job rotates an API key directly in a managed service, then fails to update the IaC state. The drift source is the automation system, even though the trigger was an intended operational workflow.
• A remote team member changes a database parameter during maintenance, creating configuration drift that persists across environments. The drift source must be linked to the maintenance ticket and the specific identity used.
• An attacker uses stolen credentials to alter infrastructure settings, similar to patterns discussed in the Salesloft OAuth token breach, turning drift analysis into an incident-response problem rather than a simple reconciliation task.
• Hard-coded secrets in legacy code paths enable out-of-band changes that later surface as drift, a risk illustrated by the Gladinet Hard-Coded Keys RCE Exploitation research and related misuse of unmanaged credentials.

For infrastructure teams, drift source analysis is also a useful bridge to incident reconstruction. It helps determine whether the change was intentional, negligent, or malicious, and whether the same identity can still make similar changes elsewhere.

Why It Matters in NHI Security

Drift source is an NHI security issue because many modern drift events are created by service accounts, API keys, or automation identities that have no human owner actively watching them. When those identities are overprivileged or poorly governed, a minor state mismatch can hide a broader compromise. NHIMG research shows that 97% of NHIs carry excessive privileges, and 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, making out-of-band change analysis a control issue rather than a reporting exercise. This is where identity governance, secret hygiene, and change detection intersect.

Teams that cannot attribute drift source quickly often lose the ability to distinguish misconfiguration from credential abuse. That delay matters because remediating the state without removing the underlying access leaves the same actor free to reintroduce the drift. The operational priority is to connect the drift event to the exact NHI, session, or tool path and then decide whether revocation, rotation, or access reduction is required. In practice, this becomes unavoidable after a breach review, when leaders discover the infrastructure changed before anyone noticed the identity behind it. The lesson aligns with the remediation and visibility themes in Ultimate Guide to NHIs and the alerting emphasis in ASP.NET machine keys RCE attack.

Related resources from NHI Mgmt Group

• How should security teams scale open-source detection tooling without creating operational drift?
• What breaks when OCSF mappings drift from upstream source schemas?
• Who is accountable when authorization replicas drift from the source of truth?
• Why do groups become a major source of least privilege drift in mature identity programs?