CI/CD pipeline secrets management: balancing speed and exposure

At a glance

What this is: This guide explains how secrets move through CI/CD pipelines and finds that platform-native storage trades convenience for wider exposure and weaker lifecycle control.

Why it matters: It matters because CI/CD secrets shape both build-time and production access, so IAM teams need controls that fit machine identity, lifecycle governance, and blast-radius reduction.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.

👉 Read Infisical's guide on managing secrets in CI/CD pipelines

Context

CI/CD secrets are the credentials that let automated pipelines test code, deploy services, and touch cloud infrastructure. The security problem is that those credentials must be available to machines while still being tightly scoped, short-lived, and recoverable when a pipeline or platform is compromised.

In practice, teams often begin with platform-native secrets because they are easy to use, but that convenience hides duplication, weak lifecycle control, and broad blast radius. For identity programmes, the issue sits squarely in machine identity governance: the pipeline is not the risk by itself, the unmanaged secret lifecycle inside it is.

Key questions

Q: How should security teams manage secrets in CI/CD pipelines?

A: Use separate identities for build, deploy, and runtime tasks, then store privileged credentials outside the pipeline in a secrets manager. Retrieve them at runtime with short-lived authentication, restrict each job to the smallest required secret set, and scan code, logs, and tickets for accidental exposure before secrets spread beyond the intended boundary.

Q: Why do CI/CD secrets create so much blast radius when they are exposed?

A: CI/CD secrets often sit close to cloud permissions, registries, and deployment systems, so one leaked credential can unlock multiple downstream resources. When the same secret is duplicated across platforms or reused across stages, compromise stops being a single event and becomes a chain of access paths that are difficult to contain.

Q: What do security teams get wrong about secrets rotation in pipelines?

A: They often assume rotation alone solves the problem. Rotation helps, but it does not fix over-scoped access, duplicated storage, or secrets that are embedded in logs and source history. If the pipeline design still grants broad standing access, the credential can be rotated and still remain dangerous.

Q: Who is accountable when a CI/CD secret leak affects production systems?

A: Accountability usually sits with the teams that own the pipeline, the secrets lifecycle, and the downstream systems that trust those credentials. A mature programme maps each credential to an owner, a purpose, and a revocation path so leaks can be traced and contained before they become a production incident.

Technical breakdown

Platform-native secrets vs external secrets managers

Platform-native secrets keep credentials inside the CI/CD tool, which makes setup simple but also concentrates risk and limits governance depth. External secrets managers shift storage out of the pipeline and let the job retrieve credentials at runtime through short-lived tokens or federated identity. That changes the security model from static distribution to controlled retrieval, which is the only way to keep automation and compartmentalisation aligned. The key technical trade-off is whether secret access is bound to the pipeline platform or to a separate identity and policy layer.

Practical implication: move high-value pipeline credentials out of the CI/CD system when you need isolation, auditability, and cross-platform control.

Least privilege in CI/CD pipelines

Least privilege in CI/CD is not a slogan, it is a routing problem. CI jobs need test secrets, CD jobs need deployment credentials, and production applications should fetch runtime secrets themselves instead of inheriting them from the build pipeline. If those boundaries blur, one compromised runner can reach beyond its intended scope, turning a test failure into production exposure. The architectural question is whether each stage has a separate identity and a separate secret set, or whether one shared secret pool powers the whole workflow.

Practical implication: split test, deployment, and runtime access into distinct identities with distinct secret scopes.

Short-lived credentials and rotation in ephemeral pipelines

CI/CD workloads are naturally transient, which makes them a strong fit for dynamic secrets and automatic expiration. A static secret in a short-lived workflow creates unnecessary dwell time, because the pipeline finishes long before the credential should still be valid. Rotation, versioning, and expiry reduce that dwell time, but only if they are enforced automatically rather than tracked manually. The mechanism matters because the smaller the credential lifetime, the smaller the window an attacker has after disclosure or misuse.

Practical implication: prefer dynamic secrets or enforced rotation wherever pipelines can authenticate at runtime instead of storing long-lived credentials.

Threat narrative

Attacker objective: The attacker aims to turn trusted automation into a foothold for production access, secret harvesting, or supply-chain manipulation.

1. Entry occurs when secrets are embedded in CI/CD platforms, logs, or repositories, giving an attacker a route into the automation layer through exposed credentials rather than application code.
2. Escalation follows when the stolen pipeline credential is over-scoped or duplicated, allowing access to cloud resources, registries, deployment systems, or downstream services beyond the original test purpose.
3. Impact comes when that access is used to alter builds, exfiltrate data, or pivot into production infrastructure, turning a single CI/CD secret leak into supply-chain compromise.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI/CD secrets are machine identities, not deployment convenience items. Once a pipeline credential can reach test systems, cloud services, or registries, it becomes an identity object with lifecycle, audit, and offboarding requirements. Treating it as a temporary configuration value is how organisations miss the control failure that turns automation into access.

Secret sprawl in pipelines creates identity blast radius, not just leakage risk. The same secret often appears in platform variables, logs, repositories, and downstream runtime contexts. That duplication means compromise is no longer a single exposure event but a distributed governance failure across the software delivery chain. Practitioners should read pipeline design as blast-radius engineering, not developer convenience.

Static secret models are still too common for environments that already behave dynamically. CI/CD is ephemeral by design, yet many teams still issue long-lived credentials into short-lived jobs. That mismatch is why rotation alone is only partial control: access should be retrieved at execution time, not preloaded as persistent trust. The implication is that pipeline governance has to move from storage policy to runtime identity.

Guide to the Secret Sprawl Challenge: this topic belongs in the wider NHI governance problem set because secret exposure is rarely isolated to one tool or one team. Once credentials move across code, chat, ticketing, and pipeline systems, offboarding and revocation become cross-platform governance tasks. Practitioners should assume secret control failure is distributed until proven otherwise.

CI/CD governance is now inseparable from supply-chain resilience. Build systems are no longer just delivery infrastructure, they are trust brokers for the software factory. That means security teams need to align secrets policy, workload identity, and access review around the pipeline stages that actually touch privileged resources. The practical conclusion is that CI/CD secrets governance must be owned as part of the identity programme, not as an engineering afterthought.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• Guide to the Secret Sprawl Challenge helps teams move from discovery to containment when secret exposure becomes a lifecycle problem.

What this signals

Secret lifecycle control has become a pipeline resilience issue, not a narrow secrets-management task. CI/CD environments now mix ephemeral workloads with long-lived credentials, which means governance teams need to watch for shared secrets, stale access, and leakage beyond code repositories. When access is still valid after exposure, containment depends on revocation speed, not just discovery.

The practical pressure point for IAM and PAM teams is ownership. If the pipeline can mint, store, and reuse credentials without a clear revocation path, then the organisation has a machine identity lifecycle problem hidden inside delivery engineering. The response should be to measure credential lifetime, reuse, and offboarding coverage with the same seriousness as human access reviews.

Secret sprawl is now a distributed identity problem: credentials are showing up in chat, ticketing, repositories, and build output, which means the control plane must extend beyond the CI/CD tool itself. That is why the governance conversation increasingly maps to the OWASP Non-Human Identity Top 10 and to NIST Cybersecurity Framework 2.0 functions such as Protect and Respond.

For practitioners

• Separate build, deploy, and runtime identities Issue different credentials for CI testing, CD deployment, and application runtime access. Do not let a single pipeline secret cover all three stages, because that collapses containment and makes one compromise far harder to scope.
• Move privileged secrets out of the CI/CD platform Store sensitive credentials in an external secrets manager and retrieve them at runtime with short-lived authentication. Keep the CI/CD tool as an execution layer, not the system of record for secret storage.
• Enforce automatic rotation and expiry Set rotation and expiration policies so secrets do not outlive the workflow that uses them. Where possible, replace static credentials with dynamic secrets that are generated on demand and die with the job.
• Scan repositories and logs for exposed credentials Run secret scanning in pre-commit, CI, and repository monitoring, then treat logs as sensitive storage rather than disposable output. Exposures in comments, tickets, and build output are still credentials and should be revoked immediately.
• Review offboarding and revocation paths Confirm that secrets linked to removed services, old projects, and retired vendors are revoked when the relationship ends. Access that survives beyond its owner is a governance defect, not an operational detail.

Key takeaways

• CI/CD secret management is an identity governance problem because pipeline credentials can reach production systems and downstream services.
• Centralised platform storage reduces friction but expands the blast radius when a CI/CD platform, log, or repository is exposed.
• Short-lived credentials, separate identities, and automatic revocation are the controls that actually reduce exposure in fast-moving delivery pipelines.

Key terms

• CI/CD secret lifecycle: The CI/CD secret lifecycle is the full path a credential takes from creation to use, rotation, revocation, and retirement inside delivery pipelines. It matters because a secret that is easy to create but hard to expire or revoke becomes a standing trust object, not a transient operational aid.
• Secret sprawl: Secret sprawl is the uncontrolled spread of credentials across code, logs, chat tools, ticketing systems, and multiple platforms. It creates both duplication and blind spots, so one exposure can survive in several places and continue to grant access long after the original leak is discovered.
• Machine identity: Machine identity is the identity assigned to a non-human workload, pipeline, service, or automation component so it can authenticate and access resources. In CI/CD, machine identity needs lifecycle management, scope boundaries, and revocation just like human access, because the machine can still hold privileged trust.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• Platform-native versus external secrets manager setup steps for real CI/CD environments
• Trade-offs between environment variables, federated identity, and runtime retrieval patterns
• Practical guidance on rotation, auditing, and compliance-ready secrets lifecycle controls
• Implementation detail for integrating secrets handling into common pipeline tools

👉 Infisical's full post covers the pipeline trade-offs, lifecycle controls, and implementation details practitioners need.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.