Supply Chain Attacks on CI-CD Pipelines - A growing problem
Build pipeline attacks are growing in frequency and impact. Learn how supply chain attacks work, where CI/CD pipelines are most exposed, and how SLSA helps reduce the risk.
The attackers didn’t breach the application. They didn’t exploit a zero-day vulnerability or social-engineer a developer into handing over credentials. They simply moved a tag.
That’s what happened afew days ago in March 2026, when the GitHub Action for Xygeni Scanner called xygeni-action — a tool used specifically to improve supply chain security — had its v5 tag quietly redirected to a malicious commit containing a command-and-control backdoor. For seven days, any organisation using uses: xygeni-action/scanner@v5 in their pipelines was unknowingly executing attacker-controlled code on their CI runners. Secrets, tokens, build artefacts, deployment credentials — all of it was within reach.
![[hacked-cicd-team.jpeg]]
CVE-2026-31976 is not an anomaly. It’s a signal. And if your organisation’s CI/CD security posture hasn’t fundamentally shifted in response to the last five years of supply chain incidents, the question isn’t whether you’ll be affected — it’s when.
This post explains how build pipeline attacks work, where the risk is concentrated, and how your engineering teams can adopt stronger controls without redesigning everything from scratch.
What Makes a Build Pipeline Attack Different
Traditional application hacking targets what you ship: the running application, its APIs, its user inputs, its network exposure. Supply chain attacks target something more fundamental — the process that produces what you ship.
A compromised CI/CD pipeline gives an attacker access upstream of your finished product. Instead of finding a way into your application after it’s deployed, they find a way into your build process before it completes. The result is that your own release tooling becomes the vector — and your organisation unwittingly signs and deploys the malicious output.
This distinction matters enormously at the executive level. Application security controls — WAFs, runtime monitoring, penetration testing — provide no protection here. The attack succeeds before those controls ever come into play.
Where Pipelines Are Most Vulnerable
A modern CI/CD pipeline is a chain of dependencies, and each link is a potential entry point. The most commonly targeted components include:
Source repositories. Pull request workflows, branch protections, and commit signing controls vary wildly across organisations. Weak repository access controls allow malicious commits to enter the codebase.
CI runners. The machines that execute your build steps. Third-party actions run on these runners with the full privileges of the CI environment — including access to secrets, environment variables, and deployment credentials.
Artifact registries. Build outputs stored in package registries or container repositories can be tampered with between build and deployment if provenance isn’t verified.
Secrets and credentials. CI pipelines require access to sensitive tokens (cloud provider credentials, signing keys, OIDC tokens). A compromised step in the pipeline can exfiltrate all of them.
Third-party actions and dependencies. This is where CVE-2026-31976 sits. Every external GitHub Action pinned to a mutable tag — @v4, @main, @latest — is a reference that can be silently redirected without your knowledge.
The common thread: implicit trust. Build pipelines have historically been treated as internal infrastructure, not as attack surfaces. That assumption is no longer tenable.
The Incidents That Made This Real
The theoretical risk of supply chain compromise became undeniable through a sequence of high-profile incidents that should be on every CTO’s radar, a list that grows longer each day.
SolarWinds (2020) remains the most consequential example. Attackers compromised the build system of SolarWinds’ Orion software, injecting a backdoor — SUNBURST — directly into the compiled software before it was digitally signed and distributed to approximately 18,000 customers, including multiple US federal agencies. The attack succeeded because the build pipeline itself was trusted without verification. npr (2021-04-16): How Russia Used SolarWinds To Hack Microsoft, Intel, Pentagon, Other Networks : NPR
Codecov (2021) involved a compromised bash uploader script that exfiltrated environment variables — including secrets and tokens — from any CI environment that ran it. Hundreds of organisations were affected before the compromise was discovered. The script was fetched directly from a URL with no integrity check. GitGuardian (2021-06-21): Codecov supply chain breach - explained step by step
tj-actions/changed-files (2023) followed the same structural pattern as CVE-2026-31976. A widely used GitHub Action was compromised; its tags were redirected to malicious commits that printed CI secrets to workflow logs. Thousands of repositories were affected. StepSecurity (2025-03-14): Harden-Runner detection: tj-actions/changed-files action is compromised
XZ Utils / liblzma Backdoor (2024) this sophisticated backdoor was introduced into the XZ compression library (liblzma) after a long-term social engineering attack by a malicious maintainer. The XZ library is a key dependency in many Linux systems, including OpenSSH. The backdoor was designed to allow remote access through compromised sshd builds. This incident highlights that even purely open-source supply chains are vulnerable, underscoring the need for rigorous code review and contribution scrutiny.
guardsix (2024-04-04): XZ Utils Backdoor: Supply Chain Vulnerability (CVE-2024-3094)
Each of these incidents exploited the same architectural weakness: a trusted external component was modified, and no verification mechanism existed to detect the change.
SLSA: A Framework Built for This Problem
Supply-chain Levels for Software Artifacts (SLSA) — pronounced “salsa” — is an open-source security framework and a project of the Open Source Security Foundation, hosted at slsa.dev. It provides a graduated set of requirements designed to improve integrity across the software supply chain, particularly within build pipelines.
SLSA doesn’t prescribe specific tools. It defines what properties a build process must demonstrate, and at what level of assurance. The current version (v1.2) defines three levels, and the core mechanism across all levels is provenance — a verifiable, signed record of how a build artefact was produced: what source it came from, what build system ran it, and what inputs were used. Without provenance, you have no way to verify that the artefact you’re deploying is the one your pipeline produced — and not something that was tampered with in transit.
How to Reduce Specific Pipeline Risks
Build integrity measures can address concrete attack vectors:
Artefact tampering — the risk that build output is modified after it leaves the build system — is mitigated through signed provenance. If the signing key belongs to the build service itself, an attacker who modifies an artefact post-build cannot produce a valid signature.
Secret exfiltration — the risk that a compromised CI step reads and transmits secrets — is constrained through hermetic, isolated builds. A hermetic build has no access to the network during execution and runs in an environment that cannot be influenced by external inputs beyond those explicitly declared.
Dependency swapping — substituting a legitimate dependency with a malicious one — is directly addressed by provenance. If the provenance record specifies the exact source commit and dependency versions used, any deviation from those inputs invalidates the provenance and fails verification.
Mutable tag exploitation — the mechanism in CVE-2026-31976 — is addressed by requiring builds to reference immutable source identifiers (commit SHAs) rather than mutable tags. Provenance that records the specific commit used makes redirected tags detectable.
Adopting SLSA Incrementally
The SLSA framework is designed for incremental adoption, not a complete overhaul of your CI/CD infrastructure.
Achieving Build Level 1
This requires automating your build and generating provenance. On platforms like GitHub Actions, you can achieve this by adding a generator like actions/attest to your workflow. This provides immediate visibility with minimal engineering effort.
Achieving Build Level 2
This level requires using a trusted build platform that can generate and sign the provenance. For teams on GitHub Actions or Google Cloud Build, these services offer native support for SLSA Build Level 2. The main change is configuration—ensuring your build platform handles provenance generation and signing.
Achieving Build Level 3
This is the most significant step. It requires a build platform that can execute steps in isolated, ephemeral, and hermetic environments. This often involves adopting a dedicated, hardened build service or significantly securing your existing runners to prevent network access and ensure build-step isolation. For most organizations, reaching SLSA Build Level 3 is a multi-quarter effort, whereas Build Levels 1 and 2 can often be achieved in days.
The Tooling and Infrastructure Changes That Support SLSA
Practical SLSA adoption depends on four categories of tooling:
Build services that natively generate SLSA-compliant provenance. GitHub Actions, Google Cloud Build, and Tekton Chains all support this. Choosing a build service with native provenance support avoids the need to implement it from scratch.
Signing infrastructure. Provenance must be signed to be verifiable. Sigstore — an open-source project backed by Google, Red Hat, and Purdue University — provides keyless signing infrastructure that integrates with most CI systems and eliminates the operational burden of managing long-lived signing keys.
Provenance generation. For GitHub Actions, can the action actions/attest generate the attestation within the workflow. And afterwards can the result be obtained by the GitHub CLI using gh attestation verify.
Policy enforcement. Generating provenance is only half the picture. The other half is verifying it at deployment time. Tools such as Sigstore’s cosign, Kyverno for Kubernetes environments, and Binary Authorization on Google Cloud enforce provenance requirements as a gate before deployment — ensuring that unsigned or tampered artefacts never reach production.
The Workflow and Culture Changes That Matter as Much as the Tooling
Technical controls are only effective in the context of the workflows and behaviours that surround them. Three cultural shifts are essential:
Least-privilege access as a default. Every CI job should declare the minimum permissions it requires, and nothing more. When a job is compromised, minimal permissions limit the blast radius.
Verification before trust on third-party actions. The implicit assumption — that a widely-used, well-maintained action is safe — has been invalidated by every major incident in this category. Every third-party action should be pinned to a commit SHA, reviewed before adoption, and monitored for changes. Tools like Renovate and Github Dependabot automate the process of keeping pinned SHAs current.
Two-person review on pipeline changes. Changes to CI/CD configuration files (.github/workflows/, Jenkinsfile, .gitlab-ci.yml) should require the same review rigour as application code — ideally more, given that a malicious pipeline change can affect every subsequent build.
Measuring SLSA Maturity and Its Place Alongside Other Frameworks
SLSA is not a standalone programme. It sits within a broader ecosystem of supply chain security standards, and organisations that treat it as part of an integrated strategy will see compounding returns.
NIST SSDF (Secure Software Development Framework) provides broader software development lifecycle guidance, of which SLSA-aligned build integrity is a component. Secure Software Development Framework | CSRC
SBOMs (Software Bills of Materials) are a prerequisite for pipeline visibility. You cannot verify what you cannot enumerate. Generating a machine-readable SBOM of your pipeline dependencies — including the GitHub Actions your workflows reference — is the starting point for any supply chain security programme. The EU Cyber Resilience Act (CRA) makes SBOM generation a regulatory requirement for organisations shipping software into European markets.
OpenSSF Scorecard automates security evaluation of open-source dependencies, scoring them against criteria like pinned actions, signed releases, and branch protection. Integrating Scorecard into your dependency review process provides continuous visibility into the security posture of your third-party components. scorecard | openssf
Communicating SLSA maturity to stakeholders — boards, customers, regulators — is increasingly straightforward. SLSA levels provide a clear, externally verifiable benchmark. An organisation that can demonstrate SLSA compliance across its production build pipelines is making a specific, auditable claim about its build integrity controls, not a vague assertion about “secure development practices.”
The Strategic Imperative for Executive Leaders
The SolarWinds attack cost the affected organisations — including the US federal government — hundreds of millions in remediation and reputational damage. Codecov compromised secrets across hundreds of engineering teams. CVE-2026-31976 affected organisations that were actively investing in supply chain security.
The pattern is consistent: the pipeline is the target, implicit trust is the vulnerability, and the cost of inaction compounds with every incident.
SLSA, paired with provenance tooling, SBOM generation, and least-privilege pipeline configuration, provides a structured and achievable path to reducing that risk. It doesn’t require rebuilding your infrastructure. It requires treating your build pipeline with the same rigour you apply to the applications it produces.
The tooling exists. The framework is documented. The incidents have made the business case. The remaining variable is organisational prioritisation — and that sits with you.