How should security teams prevent Infrastructure as Code version drift across multiple teams and repositories?

Security teams should maintain a single inventory of approved IaC versions, then compare what is deployed against that standard on an ongoing basis. The control should cover Terraform, Terragrunt, and OpenTofu across all stacks and repositories, so outdated or unapproved versions are identified early. Standardisation reduces compatibility issues, weak governance, and hidden configuration sprawl.

Why This Matters for Security Teams

IaC version drift is not just a tooling nuisance. When Terraform, Terragrunt, or OpenTofu versions diverge across teams, the same code can resolve differently, produce different plans, or fail in ways that are hard to reproduce. That creates hidden operational risk, weakens change control, and makes security review unreliable because the approved baseline is no longer the one actually in use. NIST SP 800-53 Rev 5 Security and Privacy Controls makes configuration control and system integrity a core expectation, not an optional practice.

In practice, drift usually appears first in a single repository or pipeline, then spreads through shared modules, copied workflows, and ad hoc exceptions that never get reconciled. By the time teams notice, they are debugging environment-specific failures instead of enforcing a consistent standard. The same pattern shows up in broader identity and access governance: the State of Non-Human Identity Security found that only 1.5 out of 10 organisations are highly confident in securing NHIs, which is a warning sign for any control that depends on consistency across many systems.

Security teams that treat IaC versioning as a local engineering preference tend to discover the problem only after a release breaks, a control is bypassed, or an unreviewed version becomes the de facto standard.

How It Works in Practice

The most reliable approach is to treat IaC runtime versions as a governed asset, not a developer convenience. Start with a single approved version inventory for each tool family, then enforce that inventory at the repository, pipeline, and execution layers. That means checking declared versions in code, validating the runner image or local binary used in CI, and comparing deployed state against the approved standard during continuous monitoring.

In mature environments, version enforcement is usually combined with policy-as-code and release gates. For example, a pipeline can reject Terraform plans if the required version is absent, if a module pins an unapproved release, or if a repo allows broad version ranges that drift over time. The same logic should apply to Terragrunt wrappers and OpenTofu workflows, because drift often enters through indirect dependencies rather than the root module.

Useful controls include:

• Centralised allowlist of approved IaC versions, owned by platform or security governance.
• Immutable CI images or build runners so the execution version matches the declared version.
• Pre-commit and pull request checks that block unapproved version changes.
• Scheduled scans across all repositories to find version mismatches and stale pins.
• Exception handling with expiry dates, so temporary deviations do not become permanent.

For control mapping and baseline thinking, NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful anchor, while the 2026 Infrastructure Identity Survey shows how quickly organisations lose confidence once identity and infrastructure governance become fragmented. Guidance is strongest when version drift is enforced at commit time and again in CI, because that narrows the window for unreviewed changes.

These controls tend to break down when teams can install tooling outside managed pipelines, because local binaries and one-off overrides bypass the approved execution path.

Common Variations and Edge Cases

Tighter version control often increases pipeline friction, requiring organisations to balance standardisation against developer speed and legacy compatibility. That tradeoff is especially visible in multi-team environments where older modules, vendor templates, or long-lived environments still depend on previous releases. Current guidance suggests allowing short, time-boxed exceptions rather than broad compatibility ranges, but there is no universal standard for this yet.

Edge cases usually involve shared modules, nested wrappers, or mixed tooling estates. A team may standardise Terraform but forget that Terragrunt shells out to a different binary, or allow OpenTofu in one repository while CI still executes Terraform in another. Drift also shows up when release pipelines pull versions from environment variables, because the declared code and the actual runtime can silently diverge. The practical fix is to verify both the source declaration and the execution environment.

Security teams should also watch for exceptions that are technically valid but operationally dangerous: pinned versions that are no longer patched, version ranges that span incompatible majors, and repository templates that copy old settings into new projects. The Salesloft OAuth token breach is a reminder that drift in one control plane can become a broader trust failure when governance is inconsistent. The same principle applies here: if version enforcement is not visible across repositories, it is not really enforced at all.

Related resources from NHI Mgmt Group

• How should security teams maintain visibility across large Terraform codebases spread across multiple repositories and version control systems?
• How should security teams add governance to existing Infrastructure as Code pipelines without disrupting delivery workflows?
• How should security teams extend change management across design, code, and cloud?
• How should security teams manage personnel compliance when user populations are spread across multiple identity providers?