CI/CD secret exposure shows why OIDC beats long-lived credentials

At a glance

What this is: This is an analysis of CI/CD secret exposure and the case for replacing long-lived credentials with OIDC-based, short-lived access patterns.

Why it matters: It matters because CI/CD systems often sit at the centre of cloud and deployment trust, so secret handling choices directly affect blast radius, offboarding, and compromise recovery for machine access.

👉 Read GitGuardian's analysis of CI/CD secret exposure and OIDC controls

Context

CI/CD secret exposure happens when build and deployment systems hold passwords, keys, or tokens that can be reused if the pipeline is compromised. The governance problem is not automation itself, but the assumption that secrets can safely live inside the same system that uses them.

GitGuardian uses the CircleCI breach to show why pipeline-stored credentials create avoidable trust concentration. The article then contrasts long-lived passwords with OIDC-based, short-lived access and secrets-manager retrieval for cloud and Vault integrations.

For IAM teams, the core issue is lifecycle control for non-human identities: who issues the credential, where it is stored, how quickly it expires, and what happens when the CI/CD platform itself is breached.

Key questions

Q: What breaks when CI/CD pipelines rely on static secrets?

A: Static secrets create a reusable attack path into production infrastructure. Once they are copied into workflow files, logs, runner images, or environment variables, a single compromise can expose broad access long after the original job finishes. That is why pipeline secrets should be treated as production identity, not temporary configuration.

Q: Why do long-lived credentials increase risk in modern build and deployment pipelines?

A: Long-lived credentials increase risk because they can be stolen, replayed, and reused across the build path after initial compromise. In software supply chains, that can let an attacker move from a vulnerable dependency or malicious package into CI/CD systems, signing processes, or production-facing artifacts. Short-lived, runtime-issued access narrows that window and makes each authorization easier to control and audit.

Q: How do security teams know whether OIDC is actually reducing CI/CD risk?

A: OIDC is working when workflows use short-lived tokens, the target system validates claims such as audience and repository, and no reusable secrets remain in contexts or environment variables. If access still depends on stored credentials, the risk model has not changed enough.

Q: What should teams do first after discovering that a CI pipeline may have exposed secrets?

A: The first response is to revoke and reissue any credentials, tokens, or keys that may have been exposed in the affected CI process. Teams should also verify the authenticity of build scripts and review repositories, docker images, and pipeline logs for hard coded secrets. Rapid secret rotation reduces the window for reuse while investigation continues.

Technical breakdown

Why CI/CD systems become high-value secret repositories

CI/CD platforms need authenticated access to cloud services, package registries, source repositories, and deployment targets. That operational necessity often turns them into credential concentration points where environment variables, contexts, and hardcoded tokens accumulate. The risk is not just leakage, but reuse: once a secret is available inside the pipeline, any compromise of the platform can expose everything reachable with that credential. This is a non-human identity problem because the pipeline often acts as the executor for service access, not a person. Practical implication: treat CI/CD as an access broker with a narrow trust boundary, not as a safe place to store reusable secrets.

Practical implication: Move secret storage out of the pipeline and make the CI/CD system request access only at execution time.

How OIDC replaces long-lived credentials in pipeline access

OpenID Connect lets a workflow present a short-lived identity assertion instead of a static password or access key. In the GitHub Actions pattern described here, the workflow asks a trusted identity provider for a time-bound token, then exchanges that token for target-system access only when the receiving system validates the claims. That changes the security model from credential reuse to federated, ephemeral authorisation. The important detail is that access is scoped by claims such as repository and audience, so the token is meaningful only for the expected workload and context. Practical implication: use OIDC where the target system can validate token claims and issue short-lived access in response.

Practical implication: Prefer federated, short-lived tokens for CI/CD access wherever the target platform supports OIDC.

Why secrets managers reduce but do not eliminate CI/CD risk

A secrets manager removes the need to embed the secret directly in code or pipeline configuration, but it does not remove governance requirements. The workflow still needs authenticated access to fetch the secret, and the secret manager still becomes a critical control point for policy, rotation, and audit. In the Vault example, JWT auth and bound claims constrain which repositories can retrieve a secret, which is stronger than storing that secret in the CI system itself. But the architectural lesson is broader: secrets management works best when paired with ephemeral identity and strict claim binding. Practical implication: enforce retrieval-time authorisation and rotation policy, not just central storage.

Practical implication: Bind secret retrieval to workload claims and review the secret manager as part of the trust chain.

Threat narrative

Attacker objective: The attacker objective was to obtain reusable CI/CD secrets that could be used to access downstream cloud and development systems.

1. Entry occurred through unauthorised access to CircleCI systems, which exposed the stored CI/CD secrets.
2. Credential access followed when the attacker could reach secrets kept in project contexts or environment variables.
3. Impact was the need to rotate any and all secrets stored in CircleCI, including credentials used across connected systems.

Breaches seen in the wild

• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI/CD secret storage is an identity governance failure, not just a tooling issue: when pipelines hold reusable credentials, the platform becomes part of the trust boundary for every system it can reach. That creates a concentration problem for NHI governance because the same secret may authenticate builds, deployments, and cloud actions. The practitioner conclusion is simple: if the CI/CD system is breached, the credential estate is already overexposed.

Long-lived credentials create hidden blast radius in machine access: passwords and static keys persist across jobs, logs, contexts, and third-party integrations in ways that are hard to scope after the fact. This is why the CircleCI case is not just about one vendor compromise, but about how static secrets collapse containment. The practitioner conclusion is to assume any persistent pipeline credential will eventually need full estate-wide rotation.

Ephemeral access becomes the practical control point for CI/CD governance: OIDC shifts authorisation from stored secret possession to time-bound, claim-based trust. That aligns better with modern NHI lifecycle control because access can be constrained to a specific repository, audience, and session. The practitioner conclusion is to prefer issuance-time controls over storage-time controls whenever the target platform supports federation.

Hidden secret sprawl is the real control gap this article exposes: the combination of contexts, environment variables, config files, and manual overrides means many organisations are still distributing secrets faster than they can govern them. This is why a central vault alone is not enough if the workflow still pulls long-lived credentials into the pipeline. The practitioner conclusion is to treat CI/CD secret sprawl as a governance backlog item, not an implementation detail.

OIDC is valuable because it narrows trust to the job, not the pipeline estate: claim-bound, short-lived tokens are easier to reason about than persistent credentials scattered across build systems. That does not remove the need for monitoring, but it changes what you monitor: token issuance, claim scope, and target-system trust policy become the key checkpoints. The practitioner conclusion is to align access design with the shortest possible authentication window.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: Secrets Management Buyer's Guide

What this signals

Secret sprawl is the governance problem that OIDC helps contain: once CI/CD systems become the place where credentials are stored, rotated, and reused, the organisation has effectively extended trust into the build plane. Short-lived federation changes the control point from storage to issuance, which is where machine access is easier to reason about and revoke.

Pipeline access should be treated as a non-human identity lifecycle problem: the important questions are not whether a workflow can authenticate, but how long that authentication remains valid and what scope it carries. That is why federated access, claim binding, and secret-manager retrieval belong in the same control conversation.

For practitioners

• Replace static CI/CD credentials with OIDC federation Use claim-bound, short-lived tokens for cloud and service access instead of storing reusable passwords or keys in pipelines.
• Move secrets out of pipeline storage Store credentials in a dedicated secrets manager and let workflows retrieve them at runtime rather than through project variables or contexts.
• Constrain token trust with repository and audience claims Bind each workflow identity to the smallest practical scope so only the intended repo, job, and environment can assume access.
• Prepare estate-wide rotation for every pipeline-stored secret Build a rotation plan that assumes any credential present in CI/CD, logs, or contexts must be revoked and replaced after compromise.
• Audit CI/CD secret sprawl across all build paths Inventory environment variables, contexts, config files, and automation scripts to find where secrets still bypass the vault.

Key takeaways

• CI/CD secret exposure is dangerous because the build system can become a single point of compromise for many downstream credentials.
• The article’s CircleCI example shows how quickly stored secrets can force broad rotation once a platform is breached.
• OIDC narrows risk by replacing persistent pipeline credentials with short-lived, claim-bound access that is easier to govern.

Key terms

• CI/CD secret exposure: CI/CD secret exposure is the accidental or unauthorized disclosure of credentials used by build and deployment pipelines. It includes API keys, tokens, certificates, passwords, and signing material appearing in logs, code, artifacts, environment variables, or pipeline configuration. Exposure creates immediate risk because attackers can impersonate systems, alter releases, or move laterally.
• Short-Lived Scoped Token: A short-lived scoped token is an access credential that expires quickly and only authorizes specific actions or resources. For MCP, it is the practical boundary that replaces standing access with task-limited permission, reducing blast radius when a client or agent is compromised.
• Secret Manager: A secret manager is a control that stores and sometimes rotates credentials such as tokens, keys, and certificates. It reduces exposure of sensitive material, but it does not by itself establish ownership, entitlement context, or revocation accountability, which means governance can still fail even when storage is secure.
• OIDC Federation: OIDC federation is a token-based trust model that lets one system accept identity assertions from another. It is commonly used to avoid static cross-environment credentials and to issue short-lived access based on trusted token claims. The control value depends on how tightly the trust relationships are governed.

What's in the full article

GitGuardian's full article covers the implementation detail this post intentionally leaves for the source:

• Step-by-step OIDC configuration for GitHub Actions and AWS.
• Vault JWT auth setup with bound claims for repository-scoped access.
• Hands-on workflow examples that retrieve secrets without embedding passwords in CI/CD.
• Command-level examples for creating and validating Vault secrets and roles.

👉 GitGuardian's full article shows the AWS and Vault setup details behind the OIDC pattern.

Deepen your knowledge

NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.