How should security teams govern secrets used across Pulumi stacks and pipelines?

Govern them as a shared identity problem, not as a stack feature. Assign each secret an owner, define who may request it, set a lifecycle for rotation and revocation, and centralise audit logging across IaC, CI/CD, and runtime consumers. That prevents Pulumi from becoming the only policy boundary.

Why This Matters for Security Teams

Secrets in Pulumi are not just values in a stack file. They are operational credentials that can unlock cloud APIs, deployment pipelines, and downstream services, which means a weak handling pattern in one layer can cascade across the whole delivery chain. The real risk is not whether Pulumi encrypts a secret, but whether the secret has a clear owner, a revocation path, and a policy that follows it beyond the stack boundary.

Security teams often discover that secret exposure is a lifecycle failure, not a tooling failure. The Guide to the Secret Sprawl Challenge shows how sprawl becomes the default when ownership is unclear, and the NIST Cybersecurity Framework 2.0 reinforces that access control, logging, and recovery need to work together rather than as separate checkboxes. NHIMG research also shows the scale of the problem: 88% of security professionals are concerned about secrets sprawl in the 2024 State of Secrets Management Survey by Akeyless.

In practice, many security teams encounter secret misuse only after a pipeline token, cloud key, or API credential has already been reused outside the intended stack lifecycle.

How It Works in Practice

The right model is to treat each secret as a shared identity artifact with explicit governance. That means defining an owner, an approved requesting service or pipeline, a scoped purpose, a rotation interval, and a revocation trigger. Pulumi can store and reference secrets, but the security decision should be made by the surrounding identity and secrets management controls, not by the stack alone.

For most organisations, the practical pattern is to issue short-lived credentials to the CI/CD system or runtime consumer and keep long-lived static secrets out of the deployment path wherever possible. Current guidance suggests using just-in-time issuance, narrow scopes, and central audit logs so that a secret used in IaC can be traced into build, deploy, and runtime events. This is consistent with the OWASP Non-Human Identity Top 10, which treats machine credentials as identities that require lifecycle control, and with NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets, which explains why dynamic secrets reduce blast radius when pipelines are compromised.

A workable implementation usually includes:

• separating secret storage from stack configuration so Pulumi never becomes the only policy layer
• mapping each secret to a business or platform owner for request, review, and retirement decisions
• enforcing rotation and revocation through a central secrets platform, not manual stack edits
• sending audit events from IaC, CI/CD, and runtime consumers into one logging pipeline
• blocking direct reuse of production credentials in lower environments

NHIMG’s CI/CD pipeline exploitation case study is a useful reminder that once a build system is compromised, hardcoded or overbroad secrets become an immediate path to lateral movement. These controls tend to break down in highly parallel pipelines with ad hoc service accounts because ownership, token scope, and revocation timing become impossible to keep consistent.

Common Variations and Edge Cases

Tighter secret governance often increases delivery overhead, requiring organisations to balance deployment speed against rotation discipline and approval latency. That tradeoff is real, especially in teams that use many stacks, ephemeral environments, or multiple cloud providers.

There is no universal standard for this yet, but current guidance suggests a few common patterns. For development stacks, lower-risk secrets may be scoped more broadly than production, provided the boundary is explicit and auditable. For shared pipeline credentials, short TTLs and automatic renewal are preferable to static tokens, but only if the consuming systems can handle refresh reliably. For break-glass access, organisations should document when bypasses are allowed, who approves them, and how quickly they expire.

One recurring edge case is secret propagation through third-party build plugins or deployment actions. In those environments, governance should extend to the full execution path, not just the Pulumi program. Another is inherited infrastructure, where older stacks still depend on static credentials that cannot be rotated without downtime. In those cases, the safer approach is phased migration with parallel issuance, tighter monitoring, and explicit retirement dates. The Reviewdog GitHub Action supply chain attack is a reminder that integration points can leak secrets even when the stack itself is configured correctly.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• How should security teams govern Microsoft-driven service workflows across Teams, Intune, and Entra?
• How should security teams govern identity access across Entra and other platforms?
• How should security teams govern non-human identities at scale?