Why do long-lived secrets create risk in GitOps and CI/CD pipelines?

Why Long-Lived Secrets Are Dangerous in GitOps and CI/CD

GitOps and CI/CD work best when deployment systems are predictable, repeatable, and tightly scoped. Long-lived secrets cut against that model because they remain usable long after the job that needed them has finished. If a repository, build runner, artifact store, or cluster controller is exposed, the same credential can be reused again and again. That turns a single mistake into persistent access, which is why secrets exposure in delivery pipelines is treated as a supply chain problem, not just a hygiene issue. NHI Management Group has also documented how secret sprawl persists across the wider toolchain, including the Guide to the Secret Sprawl Challenge and the CI/CD pipeline exploitation case study.

The practical risk is not only theft, but time. The longer a secret exists, the more places it can be copied, cached, logged, or embedded into automation. GitGuardian’s The State of Secrets Sprawl 2026 reports that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which shows why detection without revocation is incomplete. In practice, many security teams discover this only after a runner, repo, or integration has already been abused repeatedly.

How Short-Lived Credentials Change the Delivery Model

The main fix is to stop treating pipeline access as a standing entitlement. Instead, issue credentials at runtime, scope them to the specific job, and revoke them automatically when the job completes. That can mean exchanging a workload identity for a short-lived token, using OIDC-based federation, or retrieving secrets from a vault only when the pipeline reaches the step that actually needs them. The key idea is that the deployment window, not the repository, should define the lifetime of access.

This aligns with current best practice in both NHI governance and platform security guidance. The OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both reinforce least privilege, asset visibility, and rapid recovery as core controls. In operational terms, security teams should:

• Replace static deployment keys with ephemeral tokens issued per pipeline run.
• Bind credentials to the runner, workload, or environment that requested them.
• Rotate or revoke access automatically after the job finishes.
• Keep secrets out of source control, build logs, and shared variables whenever possible.
• Use policy checks to block privilege escalation when a job requests more access than expected.

That approach reduces blast radius because compromise of one run does not automatically expose the next run. It also makes audit trails more meaningful, since each credential maps back to a specific execution context and time bound.

These controls tend to break down when legacy deployment jobs depend on shared service accounts, long-running self-hosted runners, or manual approval gates that delay revocation.

Where the Tradeoffs and Edge Cases Appear

Tighter secret lifetimes often increase operational overhead, so organisations must balance reduced exposure against pipeline complexity. Ephemeral credentials work best when identity federation, vault integration, and policy enforcement are already mature; otherwise teams may be tempted to fall back to static keys for convenience. That is where guidance is still evolving. There is no universal standard for every pipeline pattern, especially in hybrid environments with air-gapped systems or third-party build steps.

Some edge cases are especially risky. Shared runners can leak tokens through workspace reuse. Multi-stage pipelines can pass credentials farther than intended if variables are not scoped carefully. External actions or plugins may log or cache tokens even when the pipeline itself is designed correctly. The strongest pattern is to pair short TTLs with workload identity, step-level authorization, and explicit revocation, not to rely on expiry alone. For a deeper look at how this risk spreads through real environments, the Mastra npm Supply Chain Attack — Sapphire Sleet and Reviewdog GitHub Action supply chain attack show how fast trusted automation can become a credential exposure path. The hardest failures appear in environments that mix reusable runners, broad permissions, and delayed secret rotation.

Related resources from NHI Mgmt Group

• Why do CI/CD runners create a different risk profile from long-lived workloads?
• Why do long lived static credentials create risk for infrastructure teams and service operators?
• Why do internal service certificates reduce risk compared with long-lived secrets?
• Why do long-lived API secrets and access tokens increase operational risk in identity automation?