In March 2025, a single compromised GitHub Action — tj-actions/changed-files — exposed CI secrets across more than 23,000 repositories after attackers retargeted its version tags to point at a malicious commit (CVE-2025-30066). Four years earlier, attackers spent roughly nine weeks quietly rewriting Codecov's Bash Uploader script, siphoning environment variables out of thousands of customers' CI pipelines before anyone noticed. Both incidents share a common target: the CI/CD pipeline itself, not the application it builds. A CI/CD supply chain attack compromises the automated systems that build, test, and ship software — pipelines, runners, third-party actions, and the secrets that flow through them — so that malicious code or stolen credentials ride along with every legitimate deployment. Because pipelines hold privileged access to source repositories, artifact registries, and cloud infrastructure, a single foothold can propagate to every downstream consumer, often without a single line of the "real" application code ever being touched.
What Is a CI/CD Supply Chain Attack?
A CI/CD supply chain attack is any technique that compromises the build and deployment pipeline to inject malicious code, steal credentials, or manipulate artifacts before they reach production. The OWASP CI/CD Security Top 10 (originally published by Cider Security in 2022 and later adopted by OWASP) formalized this category, with CICD-SEC-4: Poisoned Pipeline Execution (PPE) as its defining risk. Unlike a traditional application vulnerability, the attack surface here is the automation layer: .github/workflows/*.yml files, Jenkins job configs, self-hosted runners, third-party Actions/plugins, and the secrets stores (like GitHub Secrets or CircleCI environment variables) that pipelines read on every run. Attackers who compromise this layer inherit whatever trust the pipeline has — commit signing keys, npm/PyPI publish tokens, cloud IAM roles — turning a single build job into a distribution channel for malware.
How Do Attackers Actually Get Into a CI/CD Pipeline?
Attackers get in through four repeatable patterns: poisoned pipeline execution, stolen pipeline secrets, compromised third-party dependencies inside the pipeline, and hijacked build infrastructure. Direct PPE involves an attacker with write access to a repo (or a malicious pull request from an external contributor) modifying a pipeline config to run arbitrary commands during CI — GitHub disabled pull_request_target triggers by default on forks in 2021 specifically because of this pattern. Indirect PPE targets files the pipeline trusts implicitly, like a Makefile or test fixture that CI executes without review. Stolen secrets is what happened at CircleCI in January 2023, when an engineer's laptop was infected with session-token-stealing malware, letting the attacker impersonate that engineer and access customer secrets stored in the platform — CircleCI told every customer to rotate all secrets. Compromised third-party actions is the tj-actions/changed-files pattern: attackers retagged the Action's git tags (v1, v35, etc.) to point at a commit that dumped CI runner memory, including secrets, into build logs.
What Are the Most Damaging CI/CD Supply Chain Attacks on Record?
The most damaging incidents to date are SolarWinds, Codecov, CircleCI, and the 2025 tj-actions/changed-files compromise, each of which affected thousands of downstream organizations from a single pipeline breach. In the SolarWinds attack, disclosed December 13, 2020, suspected Russian state actors inserted the SUNBURST backdoor directly into the Orion software build process, and roughly 18,000 customers downloaded the trojanized update. In the Codecov breach, discovered April 1, 2021, attackers had modified the company's Bash Uploader script starting January 31, 2021, exfiltrating CI environment variables — API keys, credentials, tokens — from thousands of customer pipelines for two months before detection. The CircleCI incident, disclosed January 4, 2023, stemmed from a single infected engineer laptop and forced a platform-wide secret rotation event. And in March 2025, the tj-actions/changed-files compromise (CVE-2025-30066) briefly turned a widely-used, 23,000+ repository GitHub Action into a secret-dumping tool before GitHub and the maintainers pulled the compromised tags within a day. Each case shows the same math: one pipeline compromise, three to five orders of magnitude more victims.
Why Are CI/CD Pipelines Such High-Value Targets?
CI/CD pipelines are high-value targets because they combine privileged credentials, low visibility, and automatic trust propagation in one place. A typical pipeline holds cloud deployment roles, container registry push tokens, code-signing keys, and access to internal package repositories — often scoped far more broadly than any individual developer's laptop, because the pipeline is assumed to be "just automation." Security teams also monitor pipelines less closely than production systems: a rogue curl | bash step buried in a YAML file or a Makefile target rarely gets the same scrutiny as a production API endpoint. Finally, whatever the pipeline produces — a container image, an npm package, a signed binary — is trusted by everyone downstream who consumes it, so poisoning the build is far more efficient than attacking each consumer individually. This is precisely the mechanism that made SolarWinds and the 3CX attack (disclosed March 2023, itself triggered by a prior compromise of Trading Technologies' X_Trader software — a rare "double supply chain attack") so effective: one build-time compromise, tens of thousands of trusting downstream installs.
How Can Security Teams Detect a CI/CD Supply Chain Attack in Progress?
Security teams detect CI/CD supply chain attacks by monitoring pipeline behavior for drift, not just scanning code for known vulnerabilities. Concretely, that means: pinning third-party Actions and plugins to a full commit SHA rather than a mutable tag (GitHub's own post-mortem on tj-actions/changed-files recommended exactly this); generating a build-time SBOM for every artifact so unexpected dependencies or version swaps are visible immediately rather than discovered months later, as with Codecov; alerting on outbound network calls from CI runners to unfamiliar domains, since most pipeline malware needs to exfiltrate secrets over the network; and treating pipeline config changes (new steps, new permissions scopes, new secrets access) with the same review rigor as production code changes. Secret scanning of build logs is also critical — the tj-actions/changed-files payload worked specifically because it printed runner memory contents into logs that were, in many cases, publicly viewable on public repositories.
How Safeguard Helps
Safeguard closes the visibility gap between "code was committed" and "artifact was deployed" by generating and ingesting SBOMs directly from your CI/CD pipeline, so every build produces a verifiable, versioned record of what actually shipped. Reachability analysis then filters that SBOM against your application's real call paths, telling teams which flagged dependencies — including ones pulled in transitively through a compromised pipeline dependency — are actually exploitable in production rather than dormant. Griffin AI, Safeguard's detection engine, watches for the pipeline-specific attack patterns described above, including anomalous Action/tag changes and unexpected secret access during a run, and correlates them against known incidents like SolarWinds, Codecov, and tj-actions/changed-files. When an issue is confirmed, Safeguard opens an auto-fix pull request — pinning an Action to a vetted SHA, bumping a poisoned dependency, or rotating an exposed credential reference — so remediation lands in the same pipeline the attack targeted, closing the loop without manual triage.