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

Discovery should preserve control parity, not just detect new code

Automatic discovery in GitOps workflows matters because the first moment a Terraform path appears is also the first moment it can introduce unreviewed infrastructure intent. If discovery only indexes repositories for convenience, teams can create a fast lane around plan review, change approval, and environment scoping. The better model is to make discovery the trigger that places new code into the same governance path as established infrastructure, so the security stance does not depend on where the code lives or who created the folder. For broader control context, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for mapping change control, access control, and monitoring expectations.

In practice, many security teams encounter unmanaged Terraform only after a new path has already started creating resources outside the intended approval flow.

What automatic discovery has to do in a GitOps pipeline

In a GitOps model, discovery is not just repository scanning. It is the mechanism that decides which Terraform code is considered active, governed, and eligible for validation. That means new folders, renamed modules, new branches, and newly opened pull requests need to be registered in a way that makes them visible to the same checks as existing stacks. If discovery is brittle, teams get blind spots such as orphaned code paths, duplicate stack registrations, or code that is technically present in Git but absent from policy evaluation.

A practical implementation usually connects three layers. First, the repository event layer detects creation or change events. Second, the catalog or stack registry maps those events to an infrastructure unit that can be validated. Third, the policy and deployment layer enforces plan generation, policy-as-code review, and approval before merge or apply. The important point is that discovery should not only create an index entry. It should create a governed object with an owner, scope, and validation path.

• Detect repository and path changes consistently across branches and pull requests.
• Associate each new Terraform unit with a specific workspace, environment, or stack boundary.
• Require plan output and policy checks before a discovered stack can progress.
• Preserve ownership metadata so discovery does not create unreviewed shared responsibility gaps.

Teams also need to decide what counts as a real stack. Some organisations treat every directory as discoverable; others require a manifest, naming convention, or explicit registration file. That choice affects noise, governance overhead, and the probability of accidental exposure. The design works best when discovery and enforcement are coupled tightly enough that a newly created path cannot skip the controls already applied to older code. The guidance breaks down when discovery is treated as inventory alone and not as part of the approval boundary.

When discovery becomes noisy, incomplete, or out of sync

Tighter discovery often increases operational overhead, requiring organisations to balance coverage against false positives and registration churn. That tradeoff is real, especially in fast-moving repositories where ephemeral branches, experimental modules, and partial pull requests can look like deployable infrastructure before they are ready.

One common variation is whether to discover at the repository level or at the stack level. Repository-wide discovery improves coverage, but it can over-include non-deployable examples, tests, or reusable modules. Stack-level discovery reduces noise, but it can miss newly created paths if the registration logic is too strict. There is no universal consensus on which approach is best; the right answer depends on whether the organisation values low-friction onboarding or strict environment separation.

Another edge case is drift between discovery and approval state. A stack may be discovered correctly but still lack a current owner, policy baseline, or environment label. In that case, the discovery event is useful only if it also forces classification, otherwise the system creates visibility without governance. Teams should treat unclassified new Terraform code as a control exception, not as harmless backlog.

Discovery also needs to account for generated code and reusable modules. If automation creates Terraform files, the pipeline must still decide whether those files are subject to the same review path as hand-authored infrastructure. The policy answer is often yes, but the operational treatment may differ for templates versus deployable stacks. Automatic discovery fails when it cannot distinguish between code that should be validated and code that should merely be referenced.

Practitioner Guidance

What to prioritise: Treat discovery as an enforcement trigger, not a convenience feature. The first decision is whether a new path becomes a governed stack automatically or only after it meets naming, ownership, and validation rules.

• Require a single source of truth for stack registration so discovery does not create duplicate or conflicting records.
• Make ownership and environment classification mandatory before a new Terraform unit can progress beyond planning.
• Escalate any discovered path that cannot be mapped cleanly to a policy boundary or approval workflow.

What to verify: Confirm that every discovery event lands in the same plan, policy, and approval path as existing infrastructure. If a new repository or folder can be discovered but not evaluated, the control is only partial.

Common mistake: Teams often automate stack creation before they automate stack governance. That usually produces faster onboarding, but it also creates a larger blind spot if the newly discovered code is not tied to review gates.

Practitioner takeaway: The safest discovery model is the one that makes new Terraform code harder to bypass than to govern.

Related resources from NHI Mgmt Group

• How should security teams implement policy as code across Kubernetes and Terraform?
• How should security teams implement code scanning in SCM workflows?
• How should security teams implement automatic PII redaction in Google Drive without breaking document workflows?
• How should security teams implement unstructured data discovery across SaaS, cloud, and AI workflows?