Teams often assume deleting a secret from the latest configuration removes the risk. In reality, the credential may still exist in git history, build logs, caches, or container layers. Rotation only works when the exposed secret is revoked everywhere it could still be used.
Why This Matters for Security Teams
Secret rotation in pipelines is often treated like a cleanup task, but in CI/CD it is a containment problem. A leaked token can persist beyond the visible config file in commit history, runner caches, artifacts, logs, or image layers. Current guidance from the OWASP Non-Human Identity Top 10 and NHIMG research on the Guide to the Secret Sprawl Challenge both point to the same operational risk: rotation is only effective when the old credential is no longer usable anywhere.
That matters because pipeline secrets are rarely isolated. They are often duplicated across environments, shared by multiple jobs, or copied into temporary build steps that are not truly temporary. The result is a false sense of safety when the latest deployment is updated but the exposed credential still works somewhere else. Entro Security’s 2025 State of NHIs and Secrets in Cybersecurity reports that 62% of all secrets are duplicated and stored in multiple locations, which helps explain why manual rotation so often underperforms.
In practice, many security teams discover a “rotated” secret only after a pipeline reuse, artifact replay, or downstream service call proves the old token was never fully revoked.
How It Works in Practice
Effective rotation in pipelines starts with mapping every place the credential can exist, not just the source file. That includes repository history, CI variables, masked logs, package registries, container build layers, and any downstream systems that cached the secret for reuse. The CI/CD pipeline exploitation case study shows why attackers target these seams: once one credential is exposed, they often move laterally through the automation chain.
Practitioners should treat rotation as a coordinated event:
- Revoke the exposed secret at the authority that issued it, not only in the app configuration.
- Search for all references in source control, logs, artifacts, and build outputs.
- Invalidate cached copies in runners, image layers, and secret stores where possible.
- Replace long-lived static credentials with short-lived tokens and workload identity where the platform supports it.
- Verify that dependent jobs fail safely before re-enabling the pipeline.
NHIMG’s Guide to NHI Rotation Challenges and the Ultimate Guide to NHIs — Static vs Dynamic Secrets both reinforce that static secret create recurring cleanup work, while dynamic secret reduce the blast radius by limiting usefulness over time. Best practice is evolving toward automated revocation plus runtime issuance, but there is no universal standard for every pipeline stack yet. Rotation controls tend to break down in self-hosted runners with persistent disks because build residue survives beyond the lifecycle of the job.
Common Variations and Edge Cases
Tighter rotation often increases operational overhead, requiring organisations to balance shorter secret lifetimes against pipeline stability and incident response speed. That tradeoff becomes especially visible in monorepos, multi-tenant runners, and release pipelines that depend on many shared service accounts.
One common edge case is a secret that appears rotated in the vault but remains valid in a downstream SaaS integration or legacy deployment target. Another is a token embedded in a container image: the repository may be clean, but every pulled copy of the image still carries the credential. The Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign are reminders that pipeline exposure is often systemic, not single-point.
Current guidance suggests teams should separate “changed in config” from “revoked in reality,” and treat any secret with unknown sprawl as compromised until proven otherwise. That is why the best response is not just rotation, but lifecycle control, fast detection, and proof that every consumer has been updated or cut off.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses improper secret rotation and lingering credential exposure in pipelines. |
| NIST CSF 2.0 | PR.AC-4 | Access control must cover pipeline identities and their valid credential state. |
| NIST AI RMF | GOVERN | Pipeline secret handling needs governance, ownership, and lifecycle accountability. |
Revoke exposed secrets everywhere and verify no cached, logged, or copied token still works.
