Automatic secret rotation in CI/CD pipelines works by removing the secret, not by rotating it faster: short-lived credentials issued through OIDC federation replace static API keys and service account passwords at build time, scoped to one job and revoked the moment the job ends. Anything that genuinely has to persist, like a third-party API key or a legacy database password, goes into a secrets manager configured to rotate on a schedule instead of sitting in an environment variable file where a leaked build log can expose it for months.
- OIDC federation removes static cloud credentials from CI/CD pipelines entirely in GitHub Actions, GitLab CI, and Jenkins.
- Secrets managers like Vault or AWS Secrets Manager should auto-rotate anything that can’t go short-lived, on a fixed schedule.
- Scan every repository and build log for exposed secrets before rotation, not after – a leaked key still works until it’s revoked.
- A rotate-and-manage-secrets strategy for CI/CD pipelines fails if the service accounts behind it keep standing privileged access.
Why this matters
A CI/CD pipeline is a credential factory. It touches source code, cloud infrastructure, container registries, and production deploy targets, and every one of those touchpoints needs a secret to authenticate. When those secrets are static – a long-lived AWS access key, a hardcoded database password, a personal access token pasted into a YAML file – they become a standing attack path into production that has nothing to do with the application code itself.
Static secrets in pipelines are also the easiest kind of credential to steal, because they show up in places nobody thinks to check: fork pull requests, cached build artifacts, third-party CI plugins, and Slack notifications that echo environment variables by accident. Exposed secrets and API keys in code repositories get found by automated scanners run by attackers within hours of a public push, not weeks. Rotation without discovery is a false sense of security – you can rotate a key on a 90-day schedule while a copy of it sits in a six-month-old commit history the whole time.
How do you rotate and manage secrets automatically in CI/CD pipelines?
The process breaks into six steps that apply whether the pipeline runs on GitHub Actions, GitLab CI, CircleCI, or Jenkins in 2026:
- Replace static cloud credentials with OIDC federation. GitHub Actions, GitLab CI, and most major CI platforms can request a short-lived token from AWS, Azure, or GCP at runtime instead of storing a long-lived access key as a pipeline secret. The token is scoped to that one job and expires when the job finishes.
- Move everything that can't go short-lived into a secrets manager. Database passwords, license keys, and third-party API tokens that a vendor issues as static values still need somewhere to live. A secrets manager rotates them on a schedule and injects them into the pipeline at runtime instead of storing them in pipeline config.
- Scope every secret to a single job and repository. A build secret with access to every repo in the organization turns one compromised pipeline into an organization-wide breach. Narrow scope limits what a stolen token can reach.
- Scan repositories, build logs, and container images continuously, not on a quarterly audit cycle. Secret scanning has to run on every commit and every build artifact, because a single missed leak defeats the entire rotation schedule.
- Rotate on compromise, not just on a calendar. A fixed 90-day rotation schedule is a compliance checkbox; rotating immediately when a scanner flags an exposure is what actually stops exploitation.
- Treat CI/CD service accounts as identities with their own attack path. A build system's service account usually has broader access than the humans who wrote the pipeline realize, and it rarely gets reviewed the way a human account does.
Cyber Storage and the pipeline blast radius
Secret rotation closes one entry point. It doesn't do anything for the data a compromised pipeline can already reach before rotation kicks in. If an attacker rides a stolen build credential into a data store and starts exfiltrating, the rotation schedule you set up is irrelevant to what already left the network. Secfolio's Cyber Storage architecture encrypts data before it leaves the environment, then shards and distributes the encrypted fragments so no single system – including one reached through a compromised CI/CD job – holds a reconstructable file. An attacker who lands there finds unusable fragments, not a database dump.
Why secret rotation frequency varies
There's no single correct rotation interval, and teams that chase one number miss the factors that actually drive it:
- Secret type. A short-lived OIDC token expires in minutes by design; a signing certificate or a legacy database password might realistically need months of lead time to rotate without breaking dependent systems.
- Blast radius. A secret that can reach production data stores needs a tighter rotation window than a read-only token scoped to a staging environment.
- Regulatory driver. PCI DSS, SOX, and sector-specific frameworks set minimum rotation cadences for certain credential classes, and audits check for evidence, not intent.
- Third-party rotation support. Some vendor APIs support automated key rotation through their own API; others require a manual portal login, which slows the cycle down regardless of internal policy.
- Pipeline automation maturity. Teams still injecting secrets manually into build configs can't rotate on the same schedule as teams with a fully automated secrets manager integration.
- Number of dependent systems. A secret used by one microservice rotates cleanly; a shared secret used across a dozen pipelines requires coordinated rollout to avoid breaking builds mid-rotation.
“A secret that can’t expire is a credential an attacker never has to steal twice.”
Find exposed secrets before attackers do
Check code repositories and build logs for leaked credentials.
Is OIDC federation better than a secrets manager for CI/CD credentials?
OIDC federation is better for cloud infrastructure access; a secrets manager is better for anything that has to remain a static value. OIDC eliminates the credential entirely by issuing a short-lived token scoped to one job, which is a stronger control than any rotation schedule. A secrets manager is still necessary for third-party API keys, database passwords, and license keys that the receiving system requires as a fixed value – the two approaches work together rather than competing.
How often should CI/CD secrets be rotated?
CI/CD secrets that can go short-lived should expire in minutes through OIDC federation; secrets that must remain static typically rotate every 30 to 90 days, depending on the secret type and any regulatory minimum that applies. The number matters less than whether rotation is triggered immediately on a detected exposure, since a scanner catching a leak on day 12 of a 90-day cycle is the event that actually matters.
What happens if a CI/CD secret leaks into a public repository?
A secret leaked into a public repository is compromised the moment it's pushed, regardless of the repository's visibility settings changing afterward. Automated scanners – run by both defenders and attackers – index public commits within hours in 2026, and git history retains the exposure even after the file is deleted in a later commit. Revocation, not rotation, is the correct first response; rotation without revocation leaves the old value valid until it expires on its own schedule.
FAQ
What’s the best way to rotate secrets automatically in CI/CD pipelines?
The best approach combines OIDC federation for cloud access, which removes static credentials entirely, with a secrets manager for anything that must remain a static value, rotated on a fixed schedule. Neither one alone covers every credential type a pipeline touches.
Is a secrets manager enough, or do I still need OIDC federation?
A secrets manager alone still requires storing a long-lived cloud credential somewhere. OIDC federation removes that requirement for cloud infrastructure access, leaving the secrets manager to handle only the credentials that genuinely can’t go short-lived.
How do you rotate secrets without breaking a running pipeline?
Stagger rotation so the old and new secret are both valid during a short overlap window, then confirm every dependent job has picked up the new value before revoking the old one. Rotating and revoking in the same step is what breaks builds mid-run.
What’s the difference between rotating a secret and revoking it?
Rotating replaces a secret with a new value on a schedule; revoking invalidates a specific secret immediately, usually because it’s confirmed compromised. A rotation schedule doesn’t protect against a leak that happened between rotations – only revocation does.
Do short-lived tokens eliminate the need for secret rotation entirely?
Short-lived tokens eliminate rotation for the credentials they replace, since there’s nothing static left to rotate. They don’t cover third-party API keys or database passwords that a vendor still requires as a fixed value.
Can secret scanning catch a leak after it’s already been rotated?
Secret scanning finds a leaked value in commit history or build logs regardless of whether it’s still active, which matters because an attacker with repository access can still find the pattern and target the next rotation cycle. Scanning has to run continuously, not just after an incident.
Why do CI/CD service accounts need the same scrutiny as human accounts?
CI/CD service accounts often carry broader access than the humans running the pipeline realize, and they rarely go through the same access reviews as employee accounts. An attacker who compromises one inherits that access without needing to steal a second credential.
One last thing
The pipelines that get breached in 2026 aren't usually the ones with a bad rotation schedule – they're the ones where a secret leaked six months before anyone rotated anything. Fix discovery before you fix the calendar. A CI/CD system with continuous secret scanning and no formal rotation policy is safer than one with a strict 30-day rotation and no scanning at all, because the scanner catches the leak that actually gets exploited.
Related guides
- Securing Kubernetes and container identities
- Reducing configuration drift before it becomes an attack path
