CI/CD pipeline secrets are the real breach surface in 2026

At a glance

What this is: This is an analysis of why CI/CD pipelines have become a high-value identity target and why static secrets remain the core failure mode.

Why it matters: It matters because IAM, PAM, and NHI teams must govern pipeline access as production-grade identity, not as a convenience layer attached to DevOps tooling.

By the numbers:

• GitGuardian’s 2026 report found 28.65 million new hardcoded secrets on public GitHub in 2025, a 34% year-over-year increase.
• In the Shai-Hulud 2 supply chain attack, 59% of compromised machines were CI/CD runners rather than developer workstations.

👉 Read Aembit's analysis of CI/CD pipeline secrets and workload identity federation

Context

CI/CD pipeline identity is the set of credentials, tokens, and trust relationships that let build systems talk to cloud services, deployment targets, and third-party tools. The problem is that pipelines were designed to move code quickly, not to hold durable production access. Once secrets are embedded in build systems, a single compromise can expose infrastructure-level permissions far beyond the job that created them.

The source article argues that static credentials are the wrong trust model for modern pipelines because they persist, duplicate, and outlive the workflows that use them. Identity federation changes the pattern by issuing short-lived, scoped credentials at runtime, but federation alone does not solve multi-service governance, contextual policy, or fragmented audit trails across cloud and SaaS environments.

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 CI/CD pipelines increase lateral movement risk?

A: Pipelines often concentrate cloud keys, deployment tokens, and API credentials in one execution path. If those credentials are broadly scoped, an attacker who reaches the pipeline can move from build access into storage, registries, and production services. The risk rises when one secret is reused across multiple environments.

Q: How do security teams know whether workload identity federation is working?

A: Look for the absence of persistent secrets in workflows, short-lived credentials with narrow scope, and audit records that tie each access decision to a specific job or repository. If a team still relies on long-lived keys, duplicated credentials, or manual rotation, federation has not fully replaced the old model.

Q: What is the difference between secret rotation and workload identity federation?

A: Secret rotation keeps a persistent credential in place and replaces it on a schedule, while workload identity federation removes the stored secret from the workflow entirely. Rotation reduces exposure time, but federation removes the reusable secret material that attackers usually harvest from build systems.

Technical breakdown

Why static pipeline credentials create identity debt

Static secrets in CI/CD behave like stored trust commitments. They are copied into workflow files, environment variables, runner images, logs, and troubleshooting artifacts, which means compromise in one place often becomes compromise everywhere the secret was reused. The operational issue is not only leakage. Broad permissions are usually assigned to avoid breaking builds, so the credential often has more access than the job genuinely needs. That combination of persistence, duplication, and over-scope creates identity debt inside the delivery system.

Practical implication: treat every pipeline secret as a production credential with an owner, scope, and expiry rather than as a temporary DevOps convenience.

How workload identity federation changes CI/CD authentication

Workload identity federation replaces stored credentials with runtime proof. The pipeline presents a signed OIDC token or equivalent attestation, and the target service exchanges it for short-lived access that is tied to the specific workflow run. This removes the durable secret from the path entirely. It also reduces blast radius because access can be limited to the repository, branch, environment, or job that initiated the request. In practice, the security gain comes from eliminating reusable credential material, not just rotating it faster.

Practical implication: move deployments, test jobs, and release workflows to short-lived federated access where the platform supports it.

Why federation still leaves governance gaps at scale

Native federation solves the first mile of authentication, but large pipeline estates usually span cloud providers, SaaS services, and internal signing systems. Each destination creates a separate trust policy, audit stream, and lifecycle obligation. That fragments visibility and makes contextual enforcement hard, especially when security posture of the runner or time-based policy matters. The remaining challenge is governance across relationships, not just authentication at the point of access.

Practical implication: centralise workload access policy and logging before federation sprawl recreates the same governance problem in a new form.

Threat narrative

Attacker objective: The attacker wants production-grade access by stealing secrets from build infrastructure and reusing them across cloud and deployment systems.

1. Entry occurs when an attacker poisons a pull request, branch name, or CI script so the pipeline triggers an automated workflow that exposes secrets from the runner.
2. Credential access follows when the workflow or action leaks a personal access token, runner memory, or stored pipeline secret that unlocks downstream systems.
3. Impact occurs when those credentials are reused to reach production infrastructure, third-party services, or deployment systems beyond the original build context.

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 secrets are identity assets, not implementation details. Pipelines increasingly hold the same access value as privileged service accounts because they can reach production infrastructure, third-party APIs, and release systems. When credentials are stored in workflow files or runner memory, the delivery layer becomes an identity plane with real blast radius. Teams that still treat pipeline secrets as tooling configuration are underestimating the governance surface.

Credential persistence is the failure mode, not pipeline speed. The article’s core problem is that static secrets outlive the job that needs them. That assumption fails because a pipeline is executed repeatedly, at machine speed, and often across many environments before anyone performs a review. The implication is simple: identity governance built on periodic review cannot reliably protect credentials that are designed to be reused continuously.

Workload identity federation shifts trust from storage to runtime proof. That is the right structural direction for CI/CD because the secret never persists long enough to be stolen from logs or runner memory. But federation also exposes a new governance issue: trust relationships multiply across cloud, SaaS, and internal systems, so policy has to follow the workload rather than each individual integration. Practitioners should think in terms of governed trust paths, not isolated credential replacements.

Named concept: credential debt in delivery systems. This article shows how every extra secret, duplicate copy, and per-service exception accumulates into a hidden obligation that eventually surfaces as breach exposure. Credential debt is not just more secrets, it is the compounding governance cost of letting persistent access accrete inside pipelines. The practical conclusion is that delivery security must be managed as an identity portfolio, not as a series of one-off fixes.

Agentic AI will widen the same exposure pattern if it is allowed into pipeline workflows without identity discipline. The article correctly notes that new non-human actors will add more credentials and more touchpoints to govern. That means the problem is not only CI/CD tooling, but the growing set of machine identities that can request, relay, or misuse access inside delivery systems. Practitioners should expect the pipeline identity surface to expand, not stabilise.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a broader lifecycle view, see the Ultimate Guide to NHIs and 52 NHI Breaches Analysis for recurring failure patterns.

What this signals

Credential debt is becoming the hidden liability in delivery pipelines. As CI/CD estates grow, the security issue is no longer whether a team can rotate a key, but whether it should have issued a reusable key at all. With only 5.7% of organisations having full visibility into their service accounts, the governance model for machine identities is already incomplete in many environments.

Federation will become the default, but governance has to mature with it. Short-lived authentication reduces the value of secret theft, yet it also shifts the control problem toward trust policy design, audit completeness, and workload provenance. Teams should expect more pressure to prove who or what requested access, from where, and under which runner conditions.

Identity teams should prepare for a broader machine identity mix inside delivery systems. CI/CD is no longer just a developer platform. It is becoming the junction point where service accounts, workload identities, and agentic integrations all need the same governance discipline, which is why the separation between build security and identity security is disappearing.

For practitioners

• Inventory every pipeline credential path Map where secrets enter build systems, including workflow files, runner images, environment variables, logs, and third-party integrations. Assign an owner and expiry to each credential path so you can eliminate anonymous access points.
• Replace persistent secrets with federated workload identity Use OIDC or equivalent attestation to issue short-lived credentials bound to a specific repository, branch, environment, and job. Remove stored cloud keys from workflows wherever native federation is available.
• Reduce blast radius with job-scoped permissions Split deployment, testing, signing, and notification duties into separate identities with narrowly scoped entitlements. Do not let one build credential reach every bucket, registry, or API by default.
• Centralise trust and audit across providers Where pipelines span multiple clouds or SaaS tools, maintain a single view of workload trust relationships, access decisions, and runner posture. Fragmented audit trails make incident reconstruction slower and governance weaker.

Key takeaways

• CI/CD pipelines have become a production identity surface, and static secrets are the main reason breach impact keeps widening.
• The scale of the problem is measurable, with tens of millions of new hardcoded secrets and runner compromise now a repeatable supply chain pattern.
• Replacing stored secrets with federated workload identity is the structural change that limits blast radius and removes the reusable credential attackers want.

Key terms

• Workload Identity Federation: A method of authenticating a pipeline or workload without storing a reusable secret. The system proves its identity with a signed token or attestation, then receives short-lived credentials scoped to a specific operation. This reduces secret sprawl and makes stolen build artifacts far less valuable.
• Credential Debt: The accumulated security burden created when organisations let persistent credentials spread across systems, files, logs, and environments. In pipeline settings, credential debt grows when teams keep adding exceptions instead of replacing stored access with runtime identity. Over time, that debt becomes a breach multiplier.
• Runner Posture: The security condition of the system executing a CI/CD job, including its hardening level, isolation, logging, and trustworthiness. For build identity, runner posture matters because even correctly issued credentials can be abused if the execution environment is compromised or poorly controlled.
• Pipeline Identity Surface: The full set of identities, secrets, tokens, and trust relationships used by delivery tooling to reach external systems. It includes build jobs, service accounts, cloud roles, and integrations. When this surface is unmanaged, one compromised workflow can expose production access across multiple platforms.

Deepen your knowledge

CI/CD pipeline secrets, workload identity federation, and short-lived access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are redesigning delivery identity controls in a similar environment, it is worth exploring.

This post draws on content published by Aembit: CI/CD Pipelines: The Secret Sprawl Problem and the Promise of Workload Identity Federation. Read the original.