Blog / Security engineering
Software supply chain security: attacks, risks, and defenses
Software supply chain security explained: how supply chain attacks work, the main attack types with real examples, and the controls that defend your builds.
Software supply chain security is the practice of protecting every input and step that goes into building and shipping software: the open-source packages a team pulls in, the build pipeline that assembles them, the registry that distributes the result, and the update that lands on a user's machine. Modern software is assembled more than it is written. A typical application is mostly third-party code the team did not author and often cannot fully see, and each of those parts carries the trust of whatever used it. That is the pressure point attackers aim for. Poison one input upstream, and the compromise flows to everyone downstream who trusted it. This guide explains what the software supply chain is, how supply chain attacks work, the main attack types with real examples, and the controls that defend each stage, including the developer tooling that became a live target in 2026.
What is the software supply chain?
The software supply chain is everything that contributes to a piece of software, from the first line of source code to the moment it runs in production. It helps to see it in four stages.
Source. The code a team writes, plus the open-source libraries, frameworks, and packages it depends on. Those dependencies pull in their own dependencies, which pull in theirs, so the code you actually run is far larger than the code you wrote.
Build. The pipeline that turns source into a shippable artifact: the CI/CD system, the build tools, the scripts, and the machines that run them. A build system has access to source code, secrets, and signing keys, which makes it a high-value target.
Distribution. How the finished artifact reaches its users: package registries like npm and PyPI, container registries, app and extension stores, and update servers.
Deploy and run. Where the software lands and executes, including developer machines, servers, and the editors and tools developers use every day.
Each stage inherits trust from the one before it. When you install a package, you trust its author, the registry that served it, and the build that produced it. When a user installs your update, they trust all of that, plus you. Software supply chain security is the work of making that inherited trust something you can verify, rather than something you simply assume.
How software supply chain attacks work
A supply chain attack does not break down your front door. It compromises something you already trust and lets your own tools carry the payload in. Instead of attacking one target directly, the attacker poisons a shared upstream component (a popular library, a build server, a registry account, an editor extension) and waits for everyone downstream to pull it in through their normal process.
That is what makes these attacks efficient and hard to catch. The malicious code arrives signed, versioned, and delivered through the same channel as every legitimate update. Nothing looks out of place, because from the system's point of view nothing is: the trusted source simply shipped a new version. One compromise upstream can reach thousands of organizations that never interacted with the attacker at all.
An attacker only needs to win at one of these stages, because trust flows forward. A poisoned input at the source stage is carried through the build, published by distribution, and installed at the endpoint, all by the victim's own automation.
The main types of software supply chain attacks
Supply chain attacks take several forms, grouped by the stage they target. The table below maps the common types to a real case, and the most important ones are worth a closer look.
| Attack type | How it works | Real example |
|---|---|---|
| Vulnerable or transitive dependency | A flaw in a widely used library is inherited by every project that pulls it in, often indirectly | Log4Shell in Apache Log4j, 2021 |
| Typosquatting | A malicious package is named to resemble a popular one, so a typo or a careless install pulls in the wrong code | Lookalike npm and PyPI packages, tracked at scale by Sonatype |
| Malicious or hijacked package | An attacker publishes or takes over a package that runs hostile code on install | The Shai-Hulud npm worm, 2025 |
| Compromised build or CI | Attackers alter the build so that clean source produces a tampered artifact | SolarWinds Sunburst, 2020 |
| Stolen signing keys | Stolen keys let malware carry a valid signature and pass as trusted | Nvidia code-signing certificates leaked in 2022 |
| Poisoned release or update | A backdoor is smuggled into a new release of trusted software and shipped through its normal channel | The XZ Utils backdoor, 2024 |
| Malicious editor extension | A hostile extension runs with the developer's privileges the moment it loads | Tampered extension in an AI code editor, 2026 |
SolarWinds (2020) is the case that put supply chain attacks on every board agenda. Attackers compromised the build pipeline for SolarWinds' Orion network-management software and inserted a backdoor, known as Sunburst, into legitimate, digitally signed updates. In its SEC filing, SolarWinds estimated that fewer than 18,000 customers could have installed an affected version, while noting the number actually exploited was substantially smaller, per its 10-K. The malware was not smuggled past the victims' defenses. It was delivered by the victims' own trusted update process.
Log4Shell (2021) showed how a single dependency can expose much of the internet at once. The flaw, CVE-2021-44228, sat in Apache Log4j, a logging library embedded in countless Java applications. Most affected software did not depend on Log4j directly. Google's analysis found more than 35,000 affected Java packages, and for more than 80% of them the vulnerability was more than one level deep in the dependency tree, SecurityWeek reported. You cannot patch what you do not know you are shipping, which is the whole argument for a dependency inventory.
XZ Utils (2024) is the clearest example of patience as a weapon. Over roughly two years, a contributor using the name Jia Tan built a reputation on the xz compression project, gained maintainer rights, and then planted a backdoor in versions 5.6.0 and 5.6.1 that targeted the SSH daemon, tracked as CVE-2024-3094 and rated at the maximum severity, according to the CNCF catalog. A Microsoft engineer, Andres Freund, noticed a fraction of a second of extra login latency and traced it back before the backdoored versions reached most stable Linux distributions, as documented here. It was caught by luck as much as by process, which is the uncomfortable lesson.
The Shai-Hulud npm worm (2025) showed the attack type automating itself. First seen in September 2025, it stole developer credentials and, crucially, used any stolen npm publish token to republish itself into the victim's other packages, so each infection could seed the next. Reporting put the initial spread at 180 or more packages, with later counts higher, per Help Net Security. A worm that travels through package registries turns one careless token into a chain reaction. Stolen signing keys play a related role: after the 2022 Nvidia breach, leaked code-signing certificates were abused to sign malware so it would pass as trusted, BleepingComputer reported.
Why software supply chain security matters now
Two things make this the defining risk of the moment. The first is reach. Software has never been more interconnected, so the blast radius of a single poisoned component has never been larger. One compromised library, build server, or registry account can touch thousands of organizations in a single release. It is the same dynamic as the gap between an attack surface and an attack path: one weakness upstream becomes a ready-made route into everything downstream. At ecosystem scale the volume is hard to ignore. Sonatype reported more than 454,600 new malicious open-source packages in 2025, pushing the cumulative total it has catalogued past 1.2 million, in its 2026 State of the Software Supply Chain report.
The second is that the developer endpoint has become a front line. The move to AI-assisted coding put capable editors on millions of developer machines, and those editors run a constant stream of third-party extensions that almost no team reviews. Many popular AI code editors are forks of VS Code that pull extensions from Open VSX, a registry with lighter pre-publication vetting than Microsoft's. In 2026 that surface was tested in the open. In October, a tampered copy of a legitimate AI coding extension sat in Cursor's marketplace for about eleven hours and tried to plant an SSH backdoor on machines that installed it, with Cursor estimating up to 5,000 developers may have pulled the poisoned version, according to reporting and Cursor's own notice. Earlier in the year, researchers found dozens of counterfeit extensions on Open VSX reusing the names of real tools. We covered the pattern in malicious extensions targeting Cursor and Windsurf.
An editor extension runs with the developer's privileges and can execute the moment it loads, with no click required. That makes a developer laptop, which holds source code, SSH keys, and cloud tokens, one of the shortest paths from the open internet to production code. It also lands at a time when attackers are using AI to build and spread payloads, when AI agents are running real intrusions, and when a research model has shown it can chain exploits across browsers and operating systems.
How to secure the software supply chain
No single control fixes this, because the supply chain is a chain. The goal is to make each stage verifiable, so that a tampered input is caught rather than trusted. The practices below, drawn from guidance by CISA, NIST, and the OpenSSF, map onto the four stages.
Inventory what you ship, with an SBOM. You cannot defend what you cannot see. A software bill of materials, which CISA describes as a nested inventory, a list of ingredients that make up software components, records every component and version in a build, per CISA. When the next Log4Shell lands, an SBOM is the difference between answering "are we affected" in minutes versus weeks.
Pin and verify dependencies and publishers. Pin dependencies to exact versions and verify their integrity with lockfiles and hashes, so a package cannot change under you. Check the publisher, not just the name, to avoid typosquats, and prefer components that are actively maintained and widely reviewed.
Secure the build. Treat the build pipeline as production infrastructure, because it has access to source, secrets, and signing keys. Isolate build steps from one another, keep build definitions in version control, and generate a record of how each artifact was produced. The practices in NIST's Secure Software Development Framework exist for exactly this part.
Sign artifacts and demand provenance. Signing proves who produced an artifact; provenance proves how. The SLSA framework from the OpenSSF grades build integrity in levels, from simply producing provenance up to hardened builds where signing keys are out of reach of the build steps. Signing and provenance only help if the consumer verifies them before running the artifact.
Enforce least privilege. Scope tokens, keys, and CI credentials to the narrowest access that works, and make them short-lived. The Shai-Hulud worm spread because publish tokens could do far more than publish a single package. A credential that cannot reach your other packages cannot poison them.
Monitor registries and extensions. Watch for malicious or hijacked packages among your dependencies, and treat editor extensions as third-party code that runs with your privileges. Install from the listing you verified, pin extensions by publisher and version, and remove what you do not use.
Treat the developer endpoint as attack surface. The laptop that holds source code and cloud credentials deserves the same scrutiny as a production server. Run editors without admin rights, keep secrets out of plaintext and shell history, and rotate SSH keys and tokens if a suspect extension or package ever loaded. Fold developer tooling into your broader exposure management program rather than leaving it outside.
A supply chain is only as trustworthy as its least-verified link, and attackers have learned to aim for exactly that link.
This is why we build the way we do at Threatless, and why we build it to be AI-native. Threatless Surface works to keep an accurate, current view of an organization's exposures, including the developer tooling and third-party components that most inventories miss. Threatless CTEM is built to rank those exposures by which ones open a real path to what matters, the continuous loop that continuous threat exposure management formalizes, so teams fix the poisoned link an attacker would actually use before the ones that lead nowhere. The supply chain belongs inside that picture, treated as attack surface, not handled off to the side.
Frequently asked questions
What is software supply chain security?
Software supply chain security is the practice of protecting every component and step that goes into building and delivering software, from open-source dependencies and the build pipeline to the registries and updates that reach users. Its aim is to make sure that what you ship, and what you install, is exactly what was intended, and that a tampered input upstream is caught rather than trusted.
What is a software supply chain attack?
A software supply chain attack compromises a trusted upstream component, such as a popular library, a build server, a registry account, or an editor extension, so the malicious code is delivered to downstream users through their normal, trusted process. SolarWinds, the XZ Utils backdoor, and malicious npm packages are all examples.
What is an SBOM and why does it matter?
A software bill of materials (SBOM) is an inventory of every component and version in a piece of software, which CISA calls a key building block in software supply chain risk management. It matters because you cannot patch or assess a dependency you do not know you are running, as Log4Shell made painfully clear.
Are AI code editors a supply chain risk?
Yes. Many AI code editors are forks of VS Code that install extensions from registries with lighter vetting, and an extension runs with the developer's privileges the moment it loads. In 2026, attackers used tampered and counterfeit extensions to target these editors, which makes the developer endpoint part of the supply chain you have to defend. See our coverage of malicious extensions in Cursor and Windsurf.
How do you start securing the software supply chain?
Start with visibility: build an inventory, an SBOM, of what you actually ship, then pin and verify your dependencies, lock down the build pipeline, and scope credentials to least privilege. From there, add signing and provenance, and bring developer endpoints and their extensions into the same exposure management program as the rest of your estate.