April 28, 2026 • 5 min read • CI/CD Security Supply Chain Security SLSA OIDC AppSec

The OIDC Token Heist: Forging Build Provenance in CI/CD Pipelines

As organizations adopt SLSA standards, attackers are pivoting. Learn how compromised OIDC tokens are being used to forge build provenance and bypass CI/CD security defenses.

A futuristic dark-themed illustration showing a stylized hooded cyber thief using a digital hook to intercept glowing yellow tokens from a data stream moving between a blue CI/CD pipeline and a grey cloud vault.

By 2026, the software industry largely agreed on a standard for securing the build process: Supply Chain Levels for Software Artifacts (SLSA). Cryptographic signatures and build provenance were supposed to be the silver bullets that finally eradicated software supply chain tampering.

But attackers don't just give up when a new defense is introduced—they pivot.

Enter the OIDC Token Heist. Instead of trying to inject malicious code into the repository or compromise a developer's laptop, sophisticated threat actors are now targeting the identity of the build environment itself. By exploiting OpenID Connect (OIDC) tokens in CI/CD pipelines, attackers are successfully forging build provenance, rendering SLSA Level 3 checks completely blind to the intrusion.

The Shift: From Bad Code to Stolen Identities

In the early 2020s, the best practice for CI/CD authentication shifted from long-lived, hardcoded secrets to short-lived OIDC tokens. Platforms like GitHub Actions and GitLab CI use OIDC to request temporary credentials from cloud providers (AWS, GCP, Azure) or signing services (like Sigstore).

This was a massive security upgrade. But it created a new, highly concentrated point of failure: the ephemeral runner's runtime environment.

If an attacker can execute code inside the runner while a build is happening, they don't need to steal a permanent key. They just need to hijack the short-lived OIDC token before it expires.

A flow diagram illustrating how an attacker compromises a CI/CD runner to intercept an OIDC token from a provider, then uses that token to authorize a signing service to validate a malicious software artifact. Figure 1: The anatomy of an OIDC token exfiltration attack in a supply chain environment.

Anatomy of a Provenance Forgery Attack

How does an OIDC token heist actually unfold? The attack chain is surprisingly elegant and relies on abusing legitimate pipeline features:

The Foothold: The attacker submits a seemingly benign Pull Request, or more commonly, compromises a deep-tier, transitive dependency.
The Execution: When the CI/CD pipeline runs the build, the malicious code executes as part of the standard test or compilation suite.
The Extraction: The malicious script quietly queries the local runner environment (e.g., the ACTIONS_ID_TOKEN_REQUEST_URL in GitHub) to request an OIDC token.
The Exfiltration & Forgery: The token is quickly exfiltrated to an attacker-controlled server. The attacker then uses this valid, cryptographically sound token to sign their own malicious artifact, generating a perfectly valid provenance document.

Because the token was genuinely issued to the CI/CD platform for that specific repository, the resulting signature passes all downstream SLSA verification checks. The artifact looks 100% legitimate.

Why Traditional Defenses Fail

The danger of the OIDC Token Heist lies in its ability to bypass traditional security controls.

Secret Scanners: There are no hardcoded secrets to detect. The token is generated dynamically and exists only in memory.
Branch Protections: The attacker doesn't need to merge code to main. They just need the CI runner to execute their code during a PR check or a routine build.
SLSA Verification: The admission controllers in your Kubernetes clusters will verify the signature, see that it matches the expected OIDC identity, and happily deploy the poisoned container.

Securing the Runner Environment

Defending against provenance forgery requires shifting our focus from the artifact back to the environment that creates it. Here is how modern engineering teams are locking down their pipelines:

1. Strict Token Scoping

Never use wildcards in your OIDC trust policies. Ensure that the cloud provider or signing service validates strict sub (subject) claims. For example, the token should only be valid if it originates from the main branch, not from an untrusted PR branch.

2. Network Isolation for Ephemeral Runners

If the attacker cannot exfiltrate the token, the attack dies in the runner. Implement strict egress controls on your CI/CD runners. Builds should only be allowed to communicate with approved package registries and internal services.

3. eBPF-Based Runtime Monitoring

You cannot secure what you cannot see. Deploying eBPF-based security tools inside your CI runners allows you to monitor for anomalous behavior, such as unexpected outbound network connections or unauthorized processes attempting to access environment variables holding token request URLs.

The Bottom Line

Cryptographic provenance is only as trustworthy as the environment that generated it. As we push further into 2026, the assumption that a signed artifact is a safe artifact is no longer sufficient. We must treat our CI/CD pipelines as highly sensitive production environments—because to an attacker, your build runner's identity is the master key to your entire software supply chain.