How should security teams maintain visibility across large Terraform codebases spread across multiple repositories and version control systems?

Why This Matters for Security Teams

Large Terraform estates are often split across repositories, teams, and version control systems, which means security visibility can disappear long before a control failure is obvious. The operational risk is not just missed misconfigurations; it is unmanaged infrastructure code that keeps creating cloud resources outside policy, review, and drift detection. That is why inventory and code-path discovery are foundational, not optional, and why guidance in NHI Lifecycle Management Guide maps closely to infrastructure governance as well.

The practical problem is scale. Teams usually know the main IaC repository, but not the secondary repos, mirrored forks, or older version control systems that still contain active modules. Security teams also tend to overestimate coverage when they rely on tickets, naming conventions, or platform team memory. Current guidance suggests treating Terraform, Terragrunt, and OpenTofu as discoverable assets in their own right, similar to secrets and NHIs, because the code is where authority to create infrastructure begins. This aligns with the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls for inventory and configuration management. In practice, many security teams discover unmanaged IaC only after a production change has already been merged outside the normal review path.

How It Works in Practice

Effective visibility starts with centralised discovery across all repository sources, then classifying each path that contains Terraform, Terragrunt, or OpenTofu code. That inventory should separate managed stacks from experimental, deprecated, or shadow code so teams can apply different governance rules. One repository may contain multiple environments, while another may hold reusable modules that do not create resources directly, so path-level identification matters more than repo-level labels.

A workable operating model usually includes four steps:

• Scan all version control systems on a schedule and on new repository creation.
• Detect infrastructure-as-code file patterns, module references, and backend configurations.
• Map ownership, environment, and change pipeline for each code directory.
• Track drift between known managed stacks and anything newly discovered.

This is where The State of Non-Human Identity Security becomes operationally relevant: if organisations already struggle to maintain full visibility into connected identities and monitoring, the same fragmentation can hide IaC code paths and the access that can modify them. For implementation details, teams should pair discovery with NIST SP 800-53 Rev 5 Security and Privacy Controls and policy-as-code checks at pull request time, so newly found directories are not merely catalogued but governed.

Teams should also distinguish between the code that defines a stack and the pipeline that applies it. Visibility is incomplete if a repository is known but the deployment automation, service principal, or CI identity that executes it is not linked back to that directory. These controls tend to break down when multiple VCS platforms, manual cloning, and untracked module reuse allow the same Terraform logic to drift outside the central inventory.

Common Variations and Edge Cases

Tighter discovery often increases overhead, requiring organisations to balance coverage against repository sprawl and platform noise. That tradeoff is real, especially where teams maintain many short-lived sandboxes, vendor-managed forks, or monorepos with mixed application and infrastructure code. Best practice is evolving, but current guidance suggests prioritising code paths that can create or change production resources, then expanding coverage outward.

There are also a few edge cases that deserve explicit handling. Generated Terraform should still be inventoried if it is committed to source control, even if the source of truth is elsewhere. Terragrunt wrapper layers can hide the real deployment graph, so the inventory should follow module references rather than stop at top-level folders. OpenTofu should be treated as equivalent to Terraform for discovery and governance purposes because the security question is about infrastructure authority, not product branding.

When the estate spans multiple organisations or inherited codebases, the main failure mode is not missed files alone, but unclear ownership. In those cases, the inventory should be paired with an exception process that labels unmanaged code, assigns a reviewer, and decides whether the path is deprecated, onboarded, or quarantined. NHIMG’s Top 10 NHI Issues is a useful reminder that visibility gaps usually become control gaps, and control gaps become remediation delays.

Related resources from NHI Mgmt Group

• How should security teams reduce control drift when evidence, monitoring, and remediation are spread across multiple systems?
• How should security teams manage personnel compliance when user populations are spread across multiple identity providers?
• How should security teams build NHI governance when service accounts and secrets are spread across cloud, SaaS, and on-prem systems?
• How should security teams govern Terraform modules in private registries across large cloud environments?