How should teams implement automatic discovery for new Terraform code in GitOps workflows?

Teams should tie repository discovery to policy evaluation so new folders, branches, and pull requests are brought into the same validation path as existing infrastructure. The goal is consistent coverage, not just faster onboarding. Automatic stack creation should trigger plan checks, policy review, and approval gates before changes reach production, reducing the chance that unmanaged code bypasses controls.

Why This Matters for Security Teams

Automatic discovery is not just an onboarding convenience. In GitOps workflows, new Terraform code can appear as a new folder, branch, module, or pull request, and every one of those paths can become a control bypass if it is not evaluated with the same policy and approval logic as existing infrastructure. That risk is amplified by the fact that 30.9% of organisations still store long-term credentials directly in code, according to Ultimate Guide to NHIs.

The practical issue is coverage drift. Teams often secure the repos they know about, but GitOps systems are most exposed when a developer creates a new stack that never gets enrolled in plan checks, secret scanning, or change approval gates. NHI Management Group’s Top 10 NHI Issues shows how unmanaged secrets and identity sprawl compound quickly once code and deployment paths diverge. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports continuous control enforcement, not one-time onboarding.

In practice, many security teams encounter missing policy coverage only after a new repository has already shipped an unreviewed infrastructure change.

How It Works in Practice

Effective discovery starts by treating the repository itself as an event source. When a new Terraform repository, directory, branch, or pull request appears, the GitOps platform should automatically evaluate whether that code path contains infrastructure definitions, then register it into the same validation pipeline used for existing stacks. The discovery step should not just label the code. It should trigger plan generation, policy-as-code checks, secret scanning, and approval routing before merge or apply.

This works best when discovery is tied to repository metadata and code analysis rather than human submission. For example, path rules can identify Terraform modules, while CI signals can confirm whether the code is intended for a production boundary, a sandbox, or a shared platform account. The control objective is to prevent unmanaged code from remaining invisible long enough to bypass change management.

• Detect new repositories and new Terraform paths through Git provider webhooks or scheduled inventory scans.
• Classify the code by environment, ownership, and deployment target before any apply step.
• Force a plan review and policy evaluation on first discovery, not after the first successful deployment.
• Require approval gates for newly discovered stacks until baseline controls are proven.
• Track discovery state so deleted, renamed, or forked stacks do not fall out of governance.

Discovery should also be linked to lifecycle management. NHI Management Group’s NHI Lifecycle Management Guide is useful here because the same mindset applies: inventory, validate, approve, and continuously recheck. If discovery is paired with secret hygiene, teams can stop new Terraform code from introducing hardcoded tokens or inherited privileges that never go through review. That matters because unmanaged repo growth often becomes a hidden identity issue before it becomes a release issue.

These controls tend to break down in monorepos with weak path ownership and shared service accounts because the discovery signal is too coarse to map code to a single accountable policy set.

Common Variations and Edge Cases

Tighter discovery controls often increase pipeline noise and review overhead, so teams need to balance full coverage against developer friction. The best practice is evolving, not universal: there is no single discovery pattern that fits every GitOps operating model.

In monorepos, discovery usually needs module-level classification instead of repo-level onboarding, because one repository may contain multiple Terraform stacks with different risk profiles. In fork-heavy workflows, discovery should extend to pull request provenance so untrusted contributions do not inherit production policy automatically. In highly dynamic environments, teams may also need a quarantine state where newly discovered code can be scanned but not applied until ownership and deployment intent are confirmed.

This is where current guidance from GitHub Action tj-actions Supply Chain Attack and CI/CD pipeline exploitation case study is especially relevant: discovery is only useful if it leads to enforced validation, not passive inventory. Where teams rely on manual registration, untracked Terraform often slips through during fast-moving platform expansions or reorganisation events, especially when ownership has not been updated after a repo rename or fork.

Related resources from NHI Mgmt Group

• How should security teams add governance to existing Infrastructure as Code pipelines without disrupting delivery workflows?
• How should security teams implement manager approval workflows for infrastructure access without creating bottlenecks?
• How should security teams remediate Terraform drift without creating new deployment risk?
• How should security teams implement policy as code across Kubernetes and Terraform?