How should security teams prevent auto-discovery from creating unnecessary infrastructure stacks in GitOps workflows?

How GitOps auto-discovery turns repository structure into infrastructure scope

Auto-discovery in GitOps is useful because it reduces manual onboarding, but it also makes repository layout a control surface. If a path or module is treated as infrastructure, the deployment system may create a stack even when the code was meant to be experimental, transitional, or owned by another team. That can distort approval boundaries, trigger unnecessary deployments, and make governance harder to explain. For teams operating at pace, the question is not whether discovery should exist, but how tightly it should be constrained.

Security teams should treat discovery rules as part of platform policy, not as a convenience setting. The most important design choice is whether the discovery engine interprets presence as intent, because that assumption is what causes over-creation when repositories contain shared libraries, sandbox folders, or partially migrated services. NIST’s control family on configuration management and change control is directly relevant here because the problem is fundamentally about preventing unreviewed scope expansion in managed systems. NIST SP 800-53 Rev 5 Security and Privacy Controls gives teams a governance anchor for making discovery rules traceable to approved boundaries. In practice, many teams discover the problem only after an auto-created stack has already inherited ownership, policy, or billing expectations that were never meant to attach to it.

The practical answer is to define which repository areas are eligible for discovery and which are explicitly out of scope. That means using path allowlists, exclusion patterns, naming conventions, and ownership metadata together, rather than relying on any single signal. Discovery should reflect a deliberate operating model: what counts as a deployable unit, who owns it, and what change path is required before it can become a managed stack.

What prevents discovery noise in real GitOps pipelines

Discovery works best when the repository contains a small number of well-defined entry points and every other area is treated as non-deployable by default. If the system scans broad branches or generic directories, it will inevitably encounter code that looks stack-like without being production-ready. The operational issue is not just clutter; unnecessary stacks can create false confidence in coverage, duplicate approvals, and introduce drift between what the team thinks exists and what the platform has actually instantiated.

Effective teams usually combine four layers of control:

• Path rules that limit discovery to explicit application or environment directories.
• Ownership metadata that distinguishes managed services from shared assets and experiments.
• Change-control checks that require a reviewed transition before a new stack becomes active.
• Testing or validation gates that fail closed when repository content is ambiguous or incomplete.

This is where the workflow often breaks down: the discovery engine can be technically correct while still being organisationally wrong. A folder may contain valid configuration, but if the team has not agreed that it represents a deployable unit, the resulting stack is still an error from a governance perspective. The better pattern is to make discovery dependent on intent signals that are stable over time, not on whichever files happen to be present during a scan. That usually means codifying exclusions for deprecated branches, proof-of-concept areas, generated artefacts, and directories used by multiple teams for non-production work. Security teams should also review whether discovery is recursive by default, because overly deep scanning often turns supporting modules into separate stacks when they were only meant to feed one parent deployment.

Where auto-discovery needs tighter guardrails than teams expect

Tighter discovery usually increases operating effort, requiring teams to balance automation speed against false positives and governance overhead. That tradeoff becomes most visible in mixed repositories, large monorepos, and transitional migrations where different code states coexist for a long time. In those environments, the standard answer of “just exclude the bad paths” is often incomplete because the real problem is ambiguous ownership.

One common edge case is when a shared component is reused by several teams. If discovery treats that component as a stack in its own right, it may create duplicated infrastructure objects that no one intended to own independently. Another edge case is ephemeral work, such as migration scaffolding or feature branches that still contain valid manifests. Those artefacts can be structurally correct yet operationally inappropriate to promote. Guidance here is partly consensus and partly organisation-specific: there is broad agreement that discovery should fail closed, but the precise boundary between an application unit and a shared module depends on each team’s release model.

Security teams should also be careful about treating exclusions as a permanent cleanup mechanism. If a repository accumulates many exceptions, the discovery model becomes harder to audit and easier to misconfigure. The safer pattern is to periodically revalidate exclusions against current ownership and lifecycle state, then remove paths that no longer have a business reason to remain hidden. Where discovery and ownership conflict, the ownership model should win. Discovery is only useful when it maps to a real operating commitment, and it becomes misleading as soon as it starts creating infrastructure for code that the organisation does not actually mean to manage.

Practitioner Guidance

What to prioritise: Treat discovery scope as a policy decision, not an implementation detail. If the repository contains shared, transitional, or experimental content, make the default stance non-discoverable until a team explicitly marks it as managed.

What to verify: Confirm that every discovered stack has a clear owner, a defined deployment purpose, and an approved path into change control. If any of those three are missing, the discovery rule is too permissive.

Common mistake: Teams often tune exclusions only after stack sprawl appears. By then, the harder problem is not the pattern itself but the fact that discovery has already become an ungoverned source of infrastructure creation.

Practitioner takeaway: The healthiest GitOps discovery model is conservative by design: it should create stacks only when repository structure, ownership, and change intent all align.

Related resources from NHI Mgmt Group

• How should security teams implement manager approval workflows for infrastructure access without creating bottlenecks?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?