CI/CD pipelines are failing as secret stores, not just build systems

At a glance

What this is: This article argues that CI/CD pipelines are failing as secret stores, because static credentials in build systems turn pipeline compromise into production access.

Why it matters: IAM and platform teams need to treat CI/CD as an identity boundary, because pipeline credentials often control cloud, application and deployment access.

Context

CI/CD pipelines are often treated as delivery infrastructure, but they also act as credential brokers. When build systems hold the tokens, keys and sessions that reach production, compromise of the pipeline becomes compromise of the identities behind it.

The governance gap is not simply secrets sprawl. It is that pipelines frequently carry standing authority across environments, while incident response and access policy still assume a narrower, developer-only control plane.

The article centres on NHI governance in build and deployment systems, where secret storage, workload authentication and environment separation all determine whether a pipeline can be trusted.

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 exposed pipeline secrets create such fast compromise risk?

A: Because attackers do not need to break the application when a reusable credential already grants entry. A leaked token can be used immediately against cloud services, build tools, or connected SaaS integrations, often before defenders notice. Short-lived credentials and rapid revocation reduce that window materially.

Q: What are the signs that CI/CD security controls are not working well enough?

A: Common warning signs include secrets appearing in code or adjacent collaboration tools, policy violations that remain unresolved, weak visibility across the pipeline, and scanners that miss misconfigurations until late. If teams rely on manual review, struggle to trace findings back to owners, or cannot prioritize issues by impact, the control set is probably too fragmented to be effective.

Q: Should teams prioritise OIDC federation before secret rotation?

A: Yes, when pipelines still rely on long-lived credentials. Rotation reduces exposure, but it leaves the same architectural weakness in place. OIDC federation changes the model so the pipeline proves identity at runtime and receives temporary credentials, which removes the need to manage reusable secrets in the first place.

Technical breakdown

Why static pipeline credentials become a control-plane risk

Long-lived CI/CD variables, build logs and environment secrets create a durable attack surface because the pipeline itself becomes the place where access is stored, reused and leaked. Once a runner, engineer session or workflow file is compromised, the attacker does not need to break cloud security separately. The pipeline already holds the path into cloud APIs, deployment roles and downstream services. That is why secret storage inside delivery systems is not a convenience issue. It is an identity architecture issue where the build plane and the privilege plane have merged.

Practical implication: move pipeline authentication away from stored credentials and treat CI/CD as a governed identity source, not a secret vault.

How OIDC federation changes pipeline authentication

OIDC federation replaces shared secrets with signed identity assertions from the CI platform. The workflow proves who it is, the cloud provider verifies the token claims, and temporary credentials are issued only for the approved repository, branch or environment. That removes the bootstrap problem that static keys create, because the pipeline no longer needs a reusable credential before it can authenticate. The important design point is not just short-lived access. It is that identity is verified at runtime and authorization is bound to context such as source, branch and audience.

Practical implication: use OIDC trust relationships and claim conditions so each pipeline receives only the cloud access it can justify.

Why workload identity must extend beyond the pipeline

The same failure pattern appears again when applications still authenticate with shared passwords, static API keys or copied service account secrets. If the pipeline becomes secretless but the runtime workload still relies on long-lived credentials, the organisation has only moved the exposure point. Workload identity federation closes that gap by letting applications prove their environment and receive temporary access without storing a reusable secret. In practical terms, the security model shifts from protecting secrets at rest to verifying identity at the moment of use.

Practical implication: extend identity-based authentication to services, databases and APIs so deployment security is not undone by runtime secrets.

Threat narrative

Attacker objective: The attacker wants to turn pipeline trust into production access by stealing the credentials that the CI/CD system already authorises.

1. Entry occurs when an attacker steals a developer or engineer session, compromises a pipeline configuration, or abuses an exposed build log that contains credentials.
2. Credential access follows because the pipeline already stores tokens, keys or sessions that unlock cloud and application resources.
3. Escalation happens when those credentials are reused to deploy malicious code, request broader cloud permissions or move from a runner into production systems.
4. Impact is the exposure of secrets, unauthorized execution of pipelines and access to the permissions carried by the compromised credential set.

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.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 secret stores are now identity systems, whether teams recognise them or not. When a pipeline holds the credentials that unlock production infrastructure, the build plane becomes part of the identity plane. That shifts the governance problem from isolated secrets handling to lifecycle control over machine-authenticated access. Practitioners should treat every pipeline credential as a governed identity with scope, provenance and revocation requirements.

Static secrets in pipelines create an identity trust debt that compounds with every release. A long-lived token in a workflow file is not just a leaked secret, it is a standing trust relationship that survives beyond the branch, the build and the deploy. Once that token is copied into logs or configuration, remediation becomes reactive and incomplete. The implication is that release velocity and credential persistence are now in direct tension.

Pipeline compromise shows why least privilege must be enforced at environment boundaries, not only at application boundaries. Dev, staging and production identities cannot share credential paths if a compromised runner can inherit the wrong scope. This is where workload identity, federated authentication and environment separation become one governance model rather than three separate controls. Practitioners need to reframe CI/CD access as environment-scoped entitlement management.

Secretless delivery changes the centre of gravity from rotation to attestation. Rotation still matters for residual credentials, but the durable control is proving runtime identity at the moment a pipeline or workload asks for access. That aligns directly with OWASP-NHI, NIST-CSF access governance and zero trust principles. The practical conclusion is that pipelines should stop being places where authority is stored and start being places where authority is continuously verified.

Identity blast radius is now the decisive metric for delivery security. The more permissions a pipeline credential carries, the more likely a single compromise becomes a multi-system incident. Aembit’s examples show that a build system can expose cloud access, deployment control and downstream service authentication in one failure chain. Practitioners should measure how far one pipeline identity can move before they can claim the environment is governed.

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: CI/CD Pipeline Identity Security Guide

What this signals

Identity blast radius is now the right planning metric for delivery systems: the question is not whether a pipeline has secrets, but how far those secrets can reach if the runner is compromised. That includes cloud roles, deployment authority and downstream workload authentication, all of which should be scoped as separate entitlements rather than one shared trust path.

Teams should map CI/CD authentication to the same governance model they use for NHI lifecycle control. When build systems can issue or reuse credentials across environments, access review alone is too late because the risk is created at issuance time, not at review time.

The strongest pattern here is secretless runtime access. When pipelines and applications authenticate through identity and environment attestation instead of stored credentials, incident response shifts from emergency secret hunting to narrowing the remaining trust boundaries.

For practitioners

• Replace static pipeline credentials Scan CI/CD variables, workflow files and build logs for hardcoded keys, tokens and sessions, then remove anything that can be replayed outside the pipeline.
• Federate pipeline authentication with OIDC Configure trust relationships so GitHub Actions, GitLab CI/CD or Jenkins authenticates with signed identity assertions and receives temporary cloud credentials only for the approved scope.
• Separate deployment identities by environment Create distinct dev, staging and production service accounts with no credential overlap and no shared path from non-production runners into production.
• Extend identity-based access to workloads Replace static application passwords and API keys with workload identity federation so runtime services authenticate through environment attestation rather than stored secrets.
• Log and alert on pipeline authentication events Send every credential issuance, denial and permission grant from the pipeline into your SIEM, then alert on unusual branches, hours or resource requests.

Key takeaways

• CI/CD pipelines become breach multipliers when they store the credentials that unlock production systems.
• The article links real incidents to a familiar pattern: one compromised pipeline identity can expose secrets, trigger unauthorized execution and expand into cloud access.
• The control change that matters most is to replace persistent secrets with federated identity and environment-scoped access.

Key terms

• CI/CD Credential Broker: A CI/CD system that does more than build and deploy because it also stores or issues credentials for cloud and application access. In practice, this creates a hidden identity tier inside delivery infrastructure, where compromise of the pipeline can expose downstream permissions.
• 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.
• Workload Identity Federation: A mechanism allowing workloads in one environment to authenticate to another using short-lived tokens rather than stored credentials, based on mutual trust between identity providers.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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 building or maturing an IAM programme, it is worth exploring.