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

At a glance

What this is: This guest post examines CI/CD security after the CircleCI breach and argues for replacing long-lived credentials with OIDC-based, short-lived access and external secrets storage.

Why it matters: For IAM and NHI teams, it shows why build and deploy pipelines must be governed as high-risk identity surfaces, not treated as simple automation glue.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• Only 44% of organisations are currently using a dedicated secrets management system.

👉 Read GitGuardian's guide to CI/CD secrets, OIDC, and pipeline hardening

Context

CI/CD pipelines are identity-rich systems. They authenticate to cloud services, registries, and deployment targets, which means they often hold the same secrets that would expose production if stolen. In NHI governance terms, that makes pipeline credentials, tokens, and environment variables part of the core attack surface, not a side concern.

The CircleCI breach is a reminder that automation amplifies trust. When a pipeline stores long-lived credentials, a compromise of the CI/CD platform can become a compromise of every downstream system those credentials can reach. That is a typical failure mode in modern delivery environments, which is why controls must shift from storage convenience to identity containment.

GitGuardian’s discussion of OIDC and secrets handling is useful because it frames the real issue: how to avoid placing persistent trust in the pipeline itself. The operational answer is not just better tooling, but tighter identity design around ephemeral access, bounded roles, and external secret retrieval.

Key questions

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

A: Security teams should keep secrets out of the pipeline whenever possible and retrieve them at runtime through a secrets manager or federated identity. If a secret must exist, scope it narrowly, rotate it quickly, and bind retrieval to a specific workflow or repository. CI/CD systems should never become general-purpose secret vaults.

Q: When does OIDC improve CI/CD security more than stored credentials?

A: OIDC improves security when the target system can validate issuer, audience, and claim-based constraints, and when the workflow only needs temporary access. It reduces secret theft risk because there is no reusable credential sitting in the pipeline. It is most effective for cloud APIs, deployment roles, and other session-based access.

Q: What is the difference between secret rotation and ephemeral access?

A: Secret rotation changes a stored credential on a schedule, while ephemeral access avoids storing a long-lived credential in the first place. Rotation limits exposure time, but ephemeral access removes the standing secret from the pipeline path. For CI/CD governance, ephemeral access is the stronger control whenever the target system supports it.

Q: Should organisations treat CI/CD runners as privileged identities?

A: Yes. Runners and workflows often hold the authority to deploy, read secrets, and call cloud APIs, so they should be governed like privileged non-human identities. That means least privilege, narrow trust policies, logging, and revocation processes that assume compromise is possible.

Technical breakdown

Why CI/CD systems become high-value NHI containers

CI/CD platforms routinely act on behalf of service accounts, cloud roles, and deployment identities. They need those credentials to build images, push artefacts, call APIs, and provision infrastructure. Once secrets are stored inside the pipeline, the CI/CD system becomes a non-human identity repository with broad downstream reach. That creates a single compromise path from build automation to production access. The technical problem is not the pipeline itself, but the trust relationship it creates: the pipeline is trusted to hold credentials, and those credentials are trusted everywhere they work.

Practical implication: Treat every CI/CD credential as a production identity with a defined owner, scope, and expiry.

How OIDC replaces long-lived secrets with short-lived tokens

OpenID Connect lets a workflow exchange an authenticated token from the CI platform for a short-lived credential in the target system. Instead of storing a password or access key in the pipeline, the workflow proves its identity at runtime and receives only the access needed for that session. The target system must validate issuer, audience, and claims such as repository or branch. This shifts security from secret custody to trust policy. It also narrows the blast radius if a workflow is compromised because the token expires quickly and is bound to explicit conditions.

Practical implication: Use claim-bound OIDC trust policies for every workflow that needs cloud or secrets-manager access.

Secrets managers and rotation reduce, but do not eliminate, pipeline risk

External secrets managers remove direct secret storage from CI/CD, but they do not make the pipeline safe by default. The workflow still needs a trusted path to retrieve secrets, and the retrieval identity can still be over-scoped. Rotation helps when legacy systems cannot use ephemeral credentials, but rotation only limits dwell time if the credential is truly isolated and the access path is monitored. In practice, secret storage, retrieval policy, and rotation cadence have to be designed together. Otherwise the pipeline just moves the sensitive data to a different place without changing the exposure model.

Practical implication: Pair external secret storage with narrow retrieval permissions, short TTLs, and continuous access review.

Threat narrative

Attacker objective: The attacker wants reusable credentials that unlock cloud, deployment, or application access beyond the CI/CD platform.

1. Entry occurred through compromise of the CI/CD environment that held stored secrets and contexts.
2. Escalation followed when the attacker could use those secrets to access downstream systems beyond the pipeline.
3. Impact was the need to rotate any and all stored secrets because the trust boundary of the pipeline was no longer reliable.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed 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 pipelines are now NHI systems, not just build systems. They authenticate to multiple downstream services, carry secrets, and execute with delegated authority. That means the same governance questions applied to service accounts and workloads now apply to delivery automation. Teams that still treat pipelines as tooling rather than identities will continue to under-estimate blast radius.

Ephemeral credential trust debt is the real risk behind this pattern. Every long-lived key placed in a pipeline creates a future recovery problem when the pipeline, runner, or vendor is compromised. OIDC reduces that debt by binding access to a runtime assertion instead of a stored secret. Practitioners should measure how much of their delivery estate still depends on credentials that outlive the job they serve.

Centralising secrets without changing retrieval policy only relocates the risk. A secrets manager is necessary, but it is not sufficient if workflows can retrieve broad sets of secrets with weak claim checks or wide roles. NHI governance has to cover storage, issuance, retrieval, and revocation as one control chain. The practical conclusion is that secret vaulting must be paired with strict runtime authorization.

Pipeline compromise demonstrates why ZTA must extend into software delivery. Zero Trust Architecture is often discussed for users and endpoints, but CI/CD systems are equally dependent on continuous verification. If a workflow can assume broad privileges without tight issuer, audience, and repository constraints, the trust model is too loose. Practitioners should re-evaluate delivery pipelines as part of their zero-trust boundary, not outside it.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to Entro Security's LLMjacking analysis.
• From our research: The average time to mitigate a leaked secret is 36 hours, which shows how quickly attackers can outpace manual response, according to Akeyless's 2024 State of Secrets Management Survey.
• From our research: For a broader pattern view, the 52 NHI Breaches Analysis maps how exposed machine credentials translate into downstream compromise paths.

What this signals

Ephemeral credential trust debt is now a programme-level issue. If your delivery stack still depends on long-lived secrets, every new pipeline widens the recovery burden after compromise. Teams should inventory where CI/CD still stores credentials, then reduce the number of places where a leaked token can survive beyond a single job.

With 88% of security professionals concerned about secrets sprawl, per our 2024 State of Secrets Management Survey, the gap is not awareness but control design. CI/CD governance has to move from static secret storage to runtime authorization, expiry, and ownership tracking. That is especially true where deployment identities can reach cloud control planes.

Pipeline identity should be mapped against zero trust and workload identity standards. Pair claim-bound federation with workload identity patterns, then align the resulting trust model to NIST SP 800-63 Digital Identity Guidelines and OWASP Non-Human Identity Top 10 so that software delivery inherits the same verification discipline as human access.

For practitioners

• Replace long-lived pipeline credentials Move build and deploy workflows to short-lived credentials wherever the target system supports OIDC or workload federation. Remove access keys, passwords, and static tokens from project variables, contexts, and runner images.
• Constrain OIDC trust by claim Bind each role or policy to specific issuer, audience, repository, and branch claims so that only the intended workflow can exchange tokens. Review wildcard claims and broad org-level trust as exceptions, not defaults.

Key takeaways

• CI/CD pipelines should be governed as privileged NHI surfaces because they authenticate downstream systems and often carry the credentials that matter most.
• OIDC reduces exposure by replacing standing secrets with short-lived, claim-bound access, but only if trust policies are tightly scoped.
• Secrets managers and rotation help, yet the real control shift is from secret storage to runtime authorization and continuous verification.

Key terms

• CI/CD identity surface: The CI/CD identity surface is the set of credentials, tokens, roles, and trust relationships used by build and deploy automation. It is a non-human identity domain because workflows authenticate to other systems and can trigger high-impact actions. Governance must cover issuance, scope, rotation, and revocation.
• Ephemeral credential: An ephemeral credential is a short-lived access token or role session created for a specific task and automatically expires after use. In NHI governance, it reduces replay risk and shrinks blast radius because there is no persistent secret to steal from the pipeline or runner.
• Claim-bound trust: Claim-bound trust means a target system only grants access when a token carries approved issuer, audience, and subject claims. It is the mechanism that makes OIDC safer than stored secrets in many pipelines, because the access decision is based on runtime identity assertions rather than static credential reuse.
• Secrets manager: A secrets manager is a control plane for storing, retrieving, and sometimes rotating credentials such as keys, passwords, tokens, and certificates. It does not replace access policy. Its security value depends on how tightly retrieval is bound to identity, context, and expiry.

What's in the full article

GitGuardian's full guest post covers the operational detail this post intentionally leaves for the source:

• Step-by-step AWS OIDC trust setup, including provider, audience, and role configuration.
• GitHub Actions workflow examples showing the exact permission scope needed for id-token exchange.
• Vault JWT auth configuration and role binding details for teams that still need a secrets manager.
• Secret retrieval examples that show how runtime access works without storing credentials in the workflow.

👉 GitGuardian's full post shows the workflow examples and Vault setup details behind the controls discussed here.

Deepen your knowledge

CI/CD secret governance and OIDC-based ephemeral access are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are replacing long-lived pipeline credentials with federated identity, it is worth exploring.