How should teams govern secrets in infrastructure as code pipelines?

Why This Matters for Security Teams

Secrets governance in infrastructure as code is not just a repository hygiene problem. IaC templates are routinely copied, reviewed, forked, and promoted across environments, which makes embedded credentials easy to duplicate and hard to revoke. Once a secret lands in source control, it can be replicated into build logs, pull requests, state files, chat threads, and ticketing systems. That is why NHI Management Group treats secrets as lifecycle-managed runtime credentials, not configuration values.

Current guidance aligns with OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0: keep secrets out of code, reduce standing exposure, and make access revocable without editing infrastructure definitions. NHIMG’s Guide to the Secret Sprawl Challenge shows how quickly a single secret can multiply across environments when teams rely on manual handling instead of central control. In practice, many security teams encounter secret leakage only after a pipeline has already promoted it into multiple systems, rather than through intentional design.

How It Works in Practice

The practical pattern is simple: IaC should reference secrets by identifier, not contain the secret value itself. The pipeline resolves that reference at runtime through a dedicated secrets service, vault, or workload identity broker. This separates infrastructure intent from credential issuance, which is the key control boundary for NHI governance.

That boundary matters because the pipeline, not the repository, should decide who can fetch a secret, for how long, and under what conditions. A good implementation uses workload identity for the build runner or deployment agent, then applies policy to decide whether that identity may request a specific secret for a specific environment. This is consistent with OWASP Non-Human Identity Top 10 and the operational direction in the NIST Cybersecurity Framework 2.0.

• Use short-lived tokens or leases instead of long-lived static credentials.
• Bind secret access to pipeline identity, environment, and step-level context.
• Store only references or secret names in code, never plaintext values.
• Block commits, plan output, and state artifacts from carrying secret material.
• Rotate or revoke the secret independently of the IaC repository lifecycle.

Operationally, this means a deployment job can authenticate to the secrets service, fetch a token just in time, use it once, and lose access automatically when the job ends. NHIMG’s 230M AWS environment compromise and CI/CD pipeline exploitation case study both illustrate why pipeline trust must be tightly scoped: once an attacker reaches the build path, every embedded credential becomes a lateral movement opportunity. These controls tend to break down when state files, debug logs, or shared runners retain secret material after the job completes because cleanup is inconsistent.

Common Variations and Edge Cases

Tighter secrets control often increases pipeline complexity, requiring organisations to balance developer speed against stronger credential discipline. That tradeoff is real, especially in multi-cloud or legacy estates where every platform stores secrets differently.

There is no universal standard for this yet, but current guidance suggests using the same core model everywhere: references in code, runtime retrieval in execution, and revocation outside the repository. Where teams still use environment variables or template parameters, the main risk is accidental exposure in logs and artifact retention, not just commit history. NHIMG’s The State of Secrets in AppSec reports that only 44% of developers follow secrets best practices, which helps explain why policy must be enforced by tooling rather than assumed through training alone.

Edge cases include ephemeral review environments, imported third-party modules, and shared deployment accounts. In those environments, teams should prefer workload-bound access and narrowly scoped service identities, then treat any exception as temporary and documented. Secret scanning still has value, but it is a detection layer, not a control. The safest pattern is to make secret retrieval a runtime event, not a configuration artifact, and to ensure the IaC pipeline cannot print, persist, or promote the secret beyond the moment it is needed.

Related resources from NHI Mgmt Group

• What do teams get wrong about secrets management in pipelines and scripts?
• How should security teams govern identities used in IaC pipelines?
• How should teams close Infrastructure as Code skills gaps without slowing delivery?
• How should security teams govern non-human identities at scale?