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

At a glance

What this is: This is an analysis of how CI/CD pipelines become credential reservoirs and why static secrets, broad service accounts and weak pipeline logging turn build systems into breach paths.

Why it matters: It matters because IAM, PAM and NHI teams have to govern pipeline identities with the same discipline they apply to human and workload access, or CI/CD becomes a direct route into production.

👉 Read Aembit's guidance on eliminating CI/CD secrets and pipeline identity risk

Context

CI/CD security is no longer a narrow DevOps concern. When pipelines store long-lived tokens, cloud credentials or deployment secrets, they inherit production-level privilege and become a target for attackers who know that one compromised workflow can open multiple environments at once.

The article argues that the underlying governance failure is identity-based, not tooling-based. Static secrets, shared service accounts and weak separation between build and runtime access create a trust model that is too broad for modern delivery pipelines, especially when applications reuse the same credential patterns outside CI/CD.

Key questions

Q: How should security teams replace static credentials in CI/CD pipelines?

A: Security teams should replace stored pipeline secrets with federated, short-lived authentication such as OIDC so the workflow never holds a reusable credential. That removes the most common theft target from variables, logs and runner environments, and it makes compromise harder to replay across clouds, registries and deployment targets.

Q: Why do CI/CD pipelines create a bigger identity risk than teams expect?

A: CI/CD pipelines often hold the credentials that unlock production infrastructure, so a single compromised workflow can expose far more than build access. When the same identity also reaches cloud services, registries and deployment systems, the pipeline becomes a privileged non-human identity with a very large blast radius.

Q: What breaks when service accounts are reused across pipeline environments?

A: Reusing service accounts across dev, staging and production breaks blast-radius control because one compromised path can move into higher-value environments without a new authentication event. It also destroys accountability, since logs can no longer distinguish whether the identity acted as a low-risk build runner or a production deployer.

Q: Who is accountable when a pipeline identity exposes production secrets?

A: Accountability sits with the team that owns the pipeline identity, its permissions and its lifecycle, not just the developers who use it. That means IAM, platform security and DevOps ownership all need explicit control definitions for provisioning, review, rotation and revocation of CI/CD credentials.

Technical breakdown

Static credentials in pipelines create persistent attack surface

Long-lived API keys and tokens in CI/CD variables remain valid long after the workflow that created them has finished. That persistence makes them attractive for theft from logs, runners, build artifacts or engineer endpoints. Once an attacker gets a pipeline credential, they do not need to break the application layer separately because the pipeline often already has cloud, registry or deployment permissions. OIDC federation changes the authentication primitive by replacing stored secrets with short-lived identity assertions issued at runtime. The practical effect is that compromise becomes harder to replay and easier to scope.

Practical implication: Replace stored pipeline secrets with OIDC federation so no reusable credential exists to steal.

Workload identity for running applications removes secret dependency

The article extends the same logic beyond pipelines to the applications they deploy. Service-to-service authentication should rely on workload identity, not passwords or static tokens, because the moment a runtime secret exists, it can be copied, leaked or overused. Identity-based authentication ties access to the verified runtime environment, which lets policy decide whether a workload may connect without ever revealing a long-lived credential. This matters because CI/CD compromise and application secret sprawl are linked failure modes, not separate problems.

Practical implication: Move runtime services to identity-based authentication so application secrets do not recreate the pipeline problem.

Segregated environment identities limit blast radius

CI/CD access should be segmented by environment because development, staging and production do not need the same authority. The article shows why a compromised dev pipeline must not inherit production permissions, and why approval gates plus restricted network access are still relevant when automation is fast. Least privilege here is not only about narrower permissions. It is also about preventing an attacker from moving from a low-value build path into high-value deployment paths through reused credentials or shared identities.

Practical implication: Separate dev, staging and production identities and require explicit approval for production changes.

Threat narrative

Attacker objective: The objective is to turn CI/CD trust into production access by extracting the secrets and permissions that pipelines already hold.

1. Entry occurred when attackers stole a 2FA-backed SSO session cookie from an engineer’s laptop in the CircleCI case, while GitLab’s pipeline trigger flaw created another route into build execution.
2. Credential access followed as exposed pipeline secrets, tokens and build-log credentials became available to the attacker or unauthorized user, giving them the permissions tied to CI/CD workflows.
3. Impact came when those credentials exposed customer secrets, enabled code execution or allowed unauthorized access to production-linked infrastructure and data.

Breaches seen in the wild

• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 identities are production identities, not developer conveniences. The article shows that pipeline access often reaches cloud infrastructure, deployment systems and application secrets, which means CI/CD credentials already sit inside the production trust boundary. Treating them as secondary or lower-risk identities creates a governance blind spot. For identity programmes, the implication is straightforward: pipeline identities need the same ownership, scope control and review discipline as any privileged non-human identity.

Static credential persistence is the core failure mode behind pipeline compromise. The problem is not just that secrets exist, but that they remain reusable across time, environment and context. That persistence gives attackers a durable handle on infrastructure once they find a secret in a variable, log or config file. Practitioner conclusion: any CI/CD design that depends on long-lived credentials is carrying avoidable credential exposure debt.

Environment segregation is a blast-radius control, not an optional hardening step. The article makes clear that a compromised development path should not be able to touch production, yet shared service accounts and overlapping permissions still make that failure possible. Least privilege only works when identities are split by environment and deployment authority is separated from runtime authority. Practitioners should treat environment separation as the control that prevents one pipeline failure from becoming an enterprise incident.

Workload identity should replace secret-based bootstrap wherever possible. The article’s target state is not better hidden secrets but fewer secrets to govern at all. That aligns with the broader NHI direction of identity-based authentication for machines, services and delivery workflows. The practical conclusion is that secretless delivery is a governance outcome, not just an engineering preference.

Secret sprawl in delivery systems is a named concept worth tracking: pipeline credential inheritance. CI/CD systems inherit the permissions of whatever credentials they store, then reproduce that privilege through automated execution. When those credentials are reused across environments or mirrored into runtime services, the blast radius expands silently. Practitioners should model every pipeline secret as inherited production authority, not as a local build variable.

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.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• For the broader control picture, see 52 NHI Breaches Analysis for recurring credential-exposure patterns that turn infrastructure identity into an attacker entry point.

What this signals

Pipeline identity governance is becoming a core IAM control plane issue. When build systems can deploy, sign or fetch secrets, the control surface is no longer limited to source code. Programmes that still treat CI/CD as a developer-only concern will miss the point that the identity risk sits in the delivery path itself, not just in the code being delivered.

Pipeline credential inheritance: when a workflow stores one reusable secret, it often inherits the permissions of an entire production chain. That is why the security question is shifting from whether a secret is protected to whether the secret should exist at all. The more the delivery stack relies on short-lived federation, the less remediation depends on human memory and the more it depends on policy.

A recent NHIMG research finding shows the pace of credential sprawl is still rising, with 28.65 million new hardcoded secrets detected in public GitHub commits in 2025. For security teams, that means detection without removal is not a governance strategy. The programme signal is clear: shift monitoring toward identity-based access, secretless runtime patterns and tighter separation between build and production authority.

For practitioners

• Replace static pipeline credentials with OIDC federation Scan GitHub Actions, GitLab CI/CD and Jenkins for hardcoded credentials, then migrate each cloud connection to federated authentication so the workflow never stores a reusable token.
• Split deployment identities by environment Create separate dev, staging and production service accounts with no credential overlap, and keep production deployment rights distinct from runtime permissions.
• Extend identity-based authentication to workloads Replace service passwords and broad shared keys with workload identity, temporary tokens and policy-based access so running applications do not recreate the same secret exposure pattern.
• Log and correlate pipeline authentication events Send every credential issuance, grant, denial and unusual pipeline request into the SIEM so security teams can spot out-of-hours runs, scope drift and abnormal access patterns.
• Document pipeline-specific incident response steps Predefine which secrets to revoke, which deployments to roll back and which teams to notify when a CI/CD identity is compromised, because delay increases blast radius.

Key takeaways

• CI/CD compromise is an identity problem because pipelines often hold the credentials that unlock production systems.
• The scale of hardcoded secret exposure remains high, which means secret reuse and long-lived credentials still create avoidable breach paths.
• Federated pipeline identity, workload identity and environment separation are the controls that shrink blast radius and make compromise harder to convert into impact.

Key terms

• Pipeline Identity: The non-human identity a CI/CD system uses to authenticate to cloud services, registries, and deployment targets. In practice, it is often more privileged than teams realise because one workflow credential can unlock multiple environments, making ownership, scope, and lifecycle control essential.
• Workload Identity Federation: A method of authenticating a workload with a trusted external identity provider instead of storing a long-lived secret inside the application or pipeline. It reduces credential sprawl by issuing short-lived access at runtime and removes the bootstrap problem that static credentials create.
• Secretless Authentication: An access pattern where systems prove identity without handling reusable passwords, API keys, or tokens. The control value comes from eliminating standing secrets from configuration, logs, and build systems, which sharply reduces the number of places an attacker can steal credentials.
• Blast Radius: The amount of damage a compromised identity can cause before detection or containment. For pipelines, blast radius depends on environment separation, privilege scope, and whether deployment credentials are reused across build and runtime contexts.

Deepen your knowledge

CI/CD identity governance, secretless delivery and workload authentication are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are moving from static pipeline credentials to federated access, the course maps directly to that transition.

This post draws on content published by Aembit: CI/CD security guidance for removing static secrets and hardening pipeline identities. Read the original.