About the Author
This article was written by Ahmar Imam with over a decade of combined experience in threat intelligence, identity protection, and incident response. Ahmar is a founder of D3C Consulting, where his team monitors emerging attack campaigns daily and works directly with enterprise security teams and individual consumers to mitigate data breach risks.
Reviewed by: Senior Threat Intelligence Analyst | Certified Information Security Professional (CISSP) | Identity Management expert
Imagine shipping a security patch to 18,000 customers, and accidentally handing attackers a master key to all of them. That is exactly what happened in the SolarWinds breach of 2020. It is one of the most damaging cyberattacks in history, and it did not start with a phishing email or a brute-force login. It started inside the software build process.
Supply chain and CI/CD attacks are now among the top threats that security teams face. Instead of breaking down your front door, attackers sneak in through a side door: a trusted vendor, an open-source package, or a build pipeline step that nobody checks carefully enough.
This guide explains how these attacks work, walks through the biggest real-world cases, and gives you a practical roadmap for protecting your software supply chain. Whether you are a security engineer, a DevOps lead, or a CISO, you will leave with clear, actionable steps you can start using today.
Key Takeaway
A supply chain attack happens when a threat actor compromises software, hardware, or a third-party vendor that a target organization trusts. Instead of attacking the victim directly, attackers inject malicious code or backdoors upstream, in a vendor’s software, a build pipeline, or an open-source library, so that every customer who installs or updates the product becomes infected automatically.
CI/CD (Continuous Integration / Continuous Delivery) attacks specifically target the automated build and deployment pipelines that modern development teams use to ship code quickly.
1. What Is a Software Supply Chain Attack?
A software supply chain is the full set of components, tools, and processes that go into building and delivering software. It includes your own code, open-source libraries, third-party SDKs, cloud services, build servers, code-signing certificates, and every vendor that touches your product along the way.
A supply chain attack targets one or more of these upstream components. The attacker’s goal is simple: compromise something your target organization already trusts so that the malware or backdoor arrives via a legitimate, expected channel, a software update, a dependency install, or a container image pull.
This approach is highly effective for two reasons. First, most security controls focus on external threats. Second, organizations rarely have full visibility into everything their software depends on. Attackers exploit both blind spots.
1.1 The Attack Surface Is Bigger Than You Think
Modern applications sit on top of an enormous dependency tree. A single Node.js or Python project can pull in hundreds, sometimes thousands, of third-party packages. Each one is a potential entry point. Security researchers at Sonatype estimate that open-source download volume hit 6.6 trillion packages in 2024, up from 3.7 trillion in 2022. More downloads mean more opportunities for attackers to slip malicious code into the chain.
2. How CI/CD Pipeline Attacks Work
CI/CD pipelines automate the steps between writing code and running it in production. A typical pipeline looks something like this: a developer pushes code → a build server compiles it → automated tests run → artifacts are packaged → the package is deployed to production or published to a registry.
Each of those steps is a potential attack surface. Attackers who gain access to a CI/CD pipeline can inject malicious code at the build stage (so it never appears in the source repository), steal signing keys, exfiltrate secrets stored as environment variables, or publish backdoored packages under a trusted name.
2.1 Common CI/CD Attack Techniques
Attack Technique | What the Attacker Does |
Build server compromise | Gains access to Jenkins, GitHub Actions, or GitLab CI runners and modifies build scripts to inject malicious code into compiled artifacts. |
Secrets exfiltration | Reads environment variables (API keys, cloud credentials) that pipelines store in plaintext or weakly protected vaults. |
Dependency confusion | Publishes a malicious public package with the same name as an internal private package, tricking pip/npm into downloading the wrong one. |
Typosquatting | Registers packages with names one typo away from popular libraries (e.g., ‘reqeusts’ instead of ‘requests’) and waits for developers to misspell the install command. |
Poisoned pipeline execution (PPE) | Abuses CI/CD configurations to run attacker-controlled code inside the pipeline environment without access to the main repo. |
Compromised maintainer account | Takes over a legitimate package maintainer’s account (often via credential stuffing) and publishes a backdoored version. |
Artifact registry hijacking | Gains write access to a package registry (npm, PyPI, Docker Hub) and replaces or patches a legitimate package. |
3. Real-World Supply Chain Attacks: Major Case Studies
Theory only goes so far. The following case studies show exactly how these attacks play out in the real world and why they are so hard to catch.
3.1 SolarWinds (2020), The Attack That Changed Everything
The SolarWinds Orion attack remains the benchmark for supply chain intrusions. A threat group (widely attributed to Russia’s SVR intelligence service) inserted a backdoor, named SUNBURST, into SolarWinds’ software build process. The malicious code was compiled directly into signed, legitimate Orion software updates.
When roughly 18,000 SolarWinds customers downloaded the update, they installed the backdoor themselves. Victims included the U.S. Departments of Treasury, Commerce, and Homeland Security, along with major technology firms. The attackers then used SUNBURST as a beachhead to move laterally and steal sensitive data, in some cases remaining undetected for up to nine months.
The core lesson: a trusted software update is a perfect delivery vehicle because security teams are trained to trust signed software from known vendors.
3.2 XZ Utils Backdoor (2024), The Patient Attacker
In early 2024, a Microsoft engineer named Andres Freund noticed that SSH logins on his Debian test system were running about half a second slower than expected. That tiny anomaly led to one of the most sophisticated supply chain attacks ever discovered.
A threat actor operating under the alias ‘Jia Tan’ had spent roughly two years building trust in the XZ Utils open-source project, a widely used compression library. Over those two years, ‘Jia Tan’ submitted helpful patches, earned commit access, and eventually inserted a backdoor into the build system (not even in the main source code, but in the Autoconf build scripts). The backdoor was designed to allow unauthorized remote code execution via a specially crafted SSH public key.
Because XZ Utils ships with virtually every Linux distribution, a successful rollout could have compromised millions of servers. It was caught before reaching stable releases, but only by a razor-thin margin.
The lesson: attackers are willing to invest years of effort to earn trust in an open-source project.
3.3 3CX Supply Chain Attack (2023)
The 3CX attack demonstrated the concept of a ‘cascading’ supply chain attack, one supply chain attack spawning another. 3CX is a business phone software provider. Attackers (attributed to North Korea’s Lazarus Group) first compromised Trading Technologies, a financial software firm, to plant malware in their X_TRADER software. An employee at 3CX then installed the compromised X_TRADER software, which gave attackers a foothold inside 3CX’s build environment. The attackers then poisoned 3CX’s own Electron desktop client, which was then distributed to 3CX’s 600,000+ customers.
This attack illustrated a supply chain attack infecting another supply chain attack, a chained or cascading compromise that drastically amplifies attacker reach.
3.4 Dependency Confusion Attacks (2021–Present)
Security researcher Alex Birsan published a proof-of-concept in 2021 that exposed a fundamental flaw in how many package managers resolve dependency names. He registered public packages with the same names as known internal packages used by Apple, Microsoft, and dozens of other companies. When their build systems ran, they pulled his public package instead of the internal one, automatically, with no warnings.
This class of attack has since been exploited in the wild against banks, technology companies, and government agencies. Some versions of this attack are automated: attackers scan public code repositories for internal package names, then immediately register them on public registries.
4. Why Are These Attacks So Hard to Detect?
Supply chain attacks are effective precisely because they exploit trust. Here is why they consistently slip through traditional defenses:
- Signed code is assumed to be safe. Most organizations check whether a software update is signed by a trusted certificate. Supply chain attackers compromise the signer or insert code before signing happens.
- Security tools focus on external traffic. Intrusion detection systems, firewalls, and EDR tools are tuned to look for inbound attacks. A software update coming from a known vendor looks completely normal.
- Dependency depth is invisible. Most teams know what they directly depend on. Almost no team has visibility into the full transitive dependency tree, the libraries their libraries depend on.
- Open-source trust is informal. Package maintainers are often unpaid volunteers. A project can be adopted by millions of developers while its single maintainer has no formal security review process.
- CI/CD pipelines run with elevated privileges. Build servers often have access to production secrets, cloud credentials, and deployment keys. Compromising a pipeline can give an attacker access to everything.
- Low and slow attackers evade behavioral analytics. The XZ Utils attacker spent two years building credibility. Most anomaly detection tools look for spikes, not gradual drift.
5. How to Protect Your Software Supply Chain
Defending against supply chain attacks requires a layered approach that spans your development workflow, your vendor relationships, and your incident response plan. Below are the controls that matter most.
5.1 Generate and Maintain an SBOM (Software Bill of Materials)
An SBOM is a machine-readable inventory of every component in your software, open-source libraries, commercial SDKs, and their version numbers. Think of it as a nutrition label for your software.
The U.S. Executive Order 14028 (2021) on Improving the Nation’s Cybersecurity mandated SBOMs for software sold to the federal government. Today, SBOMs are a foundational security control for any organization that wants visibility into its supply chain.
Tools: CycloneDX, SPDX, Syft, Anchore, Grype. These integrate directly into CI/CD pipelines and can automatically scan new builds.
5.2 Adopt the SLSA Framework
SLSA (Supply chain Levels for Software Artifacts, pronounced ‘salsa’) is a security framework developed by Google and now maintained by the OpenSSF. It defines four levels of increasing supply chain integrity:
SLSA Level | Key Requirement |
Level 1 | Build process is documented and produces provenance (metadata about how the artifact was built). |
Level 2 | Build service is hosted and tamper-resistant; source is version-controlled. |
Level 3 | Build environment is hardened; provenance is authenticated by a trusted service. |
Level 4 | Two-party review; hermetic, reproducible builds; strong security guarantees end to end. |
Most organizations should target SLSA Level 2 as a realistic near-term goal and plan a roadmap toward Level 3 for critical software.
5.3 Lock and Verify Your Dependencies
- Use lock files: Always commit package-lock.json, yarn.lock, or Pipfile.lock to version control. This pins dependency versions and prevents unexpected upgrades.
- Enable dependency integrity checks: Use –require-hashes in pip, npm audit, and integrity fields in package.json to verify that downloaded packages match expected cryptographic hashes.
- Use a private artifact registry: Tools like Artifactory, AWS CodeArtifact, or Azure Artifacts act as a proxy, letting you control exactly which packages your build systems can access. This is the best defense against dependency confusion attacks.
- Set scope policies: In npm, use –registry flags or .npmrc to explicitly set your internal registry for scoped packages.
5.4 Harden Your CI/CD Pipeline
- Principle of least privilege: CI/CD runners should have only the permissions they need for each specific job, nothing more. Avoid broad IAM roles or service accounts.
- Short-lived credentials: Use OIDC-based authentication between your CI/CD system and cloud providers (GitHub Actions OIDC, for example) so that build jobs receive short-lived tokens rather than long-lived static credentials.
- Pin GitHub Actions to commit SHAs: Referencing an action by tag (uses: actions/checkout@v3) is unsafe because tags can be moved. Pin to an immutable commit SHA (uses: actions/checkout@abc123…) instead.
- Scan IaC and pipeline config files: Use tools like Checkov, tfsec, or Semgrep to catch misconfigurations in Dockerfiles, GitHub Actions YAML, and Terraform before they reach production.
- Isolate build environments: Use ephemeral, single-use build runners (not persistent agents with accumulated state) and run builds in containers with read-only filesystems where possible.
- Enable branch protection rules: Require pull request reviews and status checks before merging. Prevent force pushes to main or release branches.
5.5 Implement Vendor and Third-Party Risk Management
Your attack surface extends to every vendor whose software you deploy or integrate. A mature vendor risk management program should include:
- Pre-procurement security assessments: Use questionnaires aligned to frameworks like CSA CAIQ, SIG, or ISO 27001 Annex A before onboarding a new vendor.
- Contractual security requirements: Include SBOMs, incident notification timelines (72 hours is a reasonable baseline), and penetration testing requirements in vendor contracts.
- Continuous monitoring: Tools like BitSight, SecurityScorecard, and RiskRecon provide ongoing ratings of vendor security posture based on externally observable signals.
- Limit vendor access: Apply zero-trust principles to third-party integrations. Use API keys with minimal scopes, time-limited access tokens, and network segmentation to isolate vendor connections.
5.6 Sign and Verify Software Artifacts
Code signing creates a cryptographic link between an artifact (a binary, container image, or package) and the identity that produced it. It allows consumers to verify that what they received is exactly what the publisher intended to ship.
Sigstore is an open-source project (backed by Google, Red Hat, and Purdue University) that makes signing and verification easy and free. Its core tool, Cosign, lets you sign container images and other artifacts with OIDC-based keyless signing, meaning no long-lived signing keys that can be stolen.
For package repositories, PyPI and npm both now support or require 2FA for maintainers, and PyPI has begun a trusted publishing rollout (using OIDC) that eliminates static API tokens.
5.7 Monitor Open-Source Dependencies Continuously
A package that is safe today may have a vulnerability disclosed tomorrow. Continuous monitoring keeps you informed:
- Dependabot (GitHub) and Renovate automatically open pull requests when new versions or security patches are available.
- OSV-Scanner (Google) queries the Open Source Vulnerabilities database against your SBOM or lock files.
- Socket.dev analyzes npm and PyPI packages for suspicious behaviors, hidden network calls, obfuscated code, install scripts that run shell commands, before you install them.
- OpenSSF Scorecard rates open-source projects on security practices (CI/CD, code review, dependency updates, vulnerability disclosure) and produces a score you can include in procurement decisions.
Quick Win Checklist: 5 Things You Can Do This Week
1. Run ‘syft .’ on your most critical application repository and generate your first SBOM.
2. Audit your GitHub Actions workflows and pin all third-party actions to commit SHAs.
3. Enable Dependabot security updates on all active repositories.
4. Check whether your CI/CD service accounts have unused permissions, revoke what is not needed.
5. Register your internal package names on public registries (npm, PyPI) to prevent dependency confusion.
6. Emerging Threats: What to Watch in 2026
The supply chain threat landscape evolves quickly. These are the trends your security team should track heading into 2026 and beyond
AI-generated malicious packages. Attackers are beginning to use large language models to generate convincing, functional-looking packages that contain hidden malicious payloads. The code passes a quick human review because it looks legitimate.
Phantom packages and hallucinated dependencies. LLM coding assistants sometimes suggest package names that do not exist. Attackers monitor for these ‘hallucinated’ package names and register them on public registries, ready to serve malware to any developer who follows the AI’s suggestion.
Container image poisoning. As Kubernetes and container-based deployments grow, base image registries become high-value targets. A compromised base image (ubuntu:latest, node:18-alpine) can silently affect thousands of downstream applications.
CI/CD as a lateral movement vector. Attackers who compromise a single developer’s laptop or credentials can use CI/CD access to pivot across an organization’s entire infrastructure, cloud accounts, production databases, and all.
Cascading supply chain attacks. As demonstrated by the 3CX breach, attacks are increasingly chained: compromise vendor A to reach vendor B, use B to reach the actual targets. This makes attribution and containment far harder.
7. Compliance and Regulatory Context
Supply chain security is no longer just a best practice, it is increasingly a legal and regulatory requirement.
Regulation / Framework | Supply Chain Requirement |
U.S. Executive Order 14028 (2021) | Mandates SBOMs for software sold to the federal government; requires vendors to meet NIST Secure Software Development Framework (SSDF). |
NIST SP 800-161r1 | Comprehensive supply chain risk management (C-SCRM) guidance for federal agencies and their contractors. |
CISA Secure by Design | Encourages software manufacturers to take ownership of security outcomes, including supply chain integrity, rather than passing the burden to customers. |
EU Cyber Resilience Act (CRA, 2024) | Requires CE-marked products with digital elements to address software supply chain risks and disclose known vulnerabilities. |
ISO/IEC 27036 | International standard for supplier relationships and ICT supply chain security. |
SOC 2 Type II | Trust Services Criteria covering vendor management and change management controls relevant to CI/CD security. |
8. Building a Supply Chain Security Program: Where to Start
If you are building a supply chain security program from scratch, the volume of controls can feel overwhelming. Use this phased approach to make steady, measurable progress:
Phase 1: Visibility (Months 1–2)
- Inventory all software you build, buy, and consume as open-source.
- Generate SBOMs for your top three critical applications.
- Map your CI/CD pipeline: identify all runners, secrets, and third-party actions.
- Assess your top five external vendors against a basic security questionnaire.
Phase 2: Control (Months 3–6)
- Deploy a private artifact registry and configure dependency proxying.
- Implement branch protection rules and pipeline approval gates for production deployments.
- Rotate to short-lived credentials (OIDC) in all CI/CD pipelines.
- Enable automated vulnerability scanning (SBOM + CVE database correlation) in your pipeline.
Phase 3: Assurance (Months 7–12)
- Achieve SLSA Level 2 for your most critical software components.
- Implement artifact signing with Sigstore/Cosign for container images and build outputs.
- Establish a formal vendor security review process with contractual SLAs.
- Run a tabletop exercise simulating a supply chain compromise (e.g., a backdoored dependency reaches production).
Conclusion
Supply chain and CI/CD attacks represent one of the most significant shifts in the modern threat landscape. Attackers have learned that it is often easier to compromise a trusted vendor or an overlooked open-source package than to break through a well-hardened perimeter. The SolarWinds breach, the XZ Utils backdoor, and the 3CX attack all followed this same logic, find the trust, exploit the trust.
The good news is that effective defenses exist. Generating SBOMs, adopting the SLSA framework, hardening CI/CD pipelines, locking dependencies, and implementing continuous monitoring are all proven, practical controls. None of them require a massive budget, many of the best tools are open-source.
The key is to start. Run a single Syft scan on your most critical application today. Pin your GitHub Actions. Enable Dependabot. Those three steps alone will meaningfully reduce your exposure and give your team the momentum to build toward a comprehensive supply chain security program.
Your supply chain is only as secure as its weakest link. Find that link before an attacker does.
