Your security depends on decisions made inside companies you have never audited. The payroll platform, the remote access tool your IT provider signs into every morning, the open source package a developer pulled in on a Tuesday afternoon: each one is a door into your systems, and somebody else holds the key. A supply chain attack is what happens when an attacker takes that key rather than trying yours, and the payload then arrives through the channel you trained everyone to trust.
What Is a Supply Chain Attack?
A supply chain attack is an attack that reaches its real target indirectly, by compromising something the target already trusts: a software vendor, an open source package, a managed service provider, a hosted platform, or a contractor with a login. The target is not breached in the usual sense. It installs the breach, or grants it, through a relationship it deliberately created.
Two things suppliers hold, and each one is a different attack.
The first is code. Software you install runs with the privileges you gave it, and an update you did not read is still an update you executed. If an attacker can add something to the vendor's build before it ships, every customer runs it, and antivirus tends not to argue with a file the vendor signed.
The second is access. Your IT provider has administrator rights. Your marketing platform holds your customer list. Your billing processor can move money. None of that code needs to be tampered with for the attacker to profit, because the account already reaches everything the account was designed to reach.
That is why the category cuts across the rest of the threat landscape rather than sitting beside it. A supply chain attack is a route, not a payload. What arrives at the end of the route might be ransomware, espionage, credential theft or fraud, and the same route delivers all four.
The federal framing is the same. CISA and NIST publish guidance on defending against software supply chain attacks built on two of NIST's own frameworks, the Cyber Supply Chain Risk Management framework and the Secure Software Development Framework, and organized around prevention, mitigation and resilience. The word resilience is doing real work there. Nobody serious claims you can prevent all of these.
How Does a Supply Chain Attack Work?
Every version of this attack has two halves. The upstream half is the break-in at the supplier. The downstream half is the delivery to the supplier's customers, which the supplier performs on the attacker's behalf, usually through an automated process nobody watches.
Getting upstream is not exotic. Attackers use stolen developer credentials, a phishing call to a support desk, an unpatched server on the vendor's edge, or a maintainer account on a package nobody thought was important. Most of the recent cases came down to talking a person into something or reusing a token that was never rotated.
- Attacker gets into the supplierStolen developer credentials, a phishing call, or an unpatched server
- Something is changed upstreamA build, a package version, an update, or a connected application
- The vendor ships it as normalSigned, versioned and pushed through the usual channel
- Customers install itThousands at once, often automatically, often overnight
- The code runs with inherited trustIt has whatever access the legitimate product already had
- Only a few victims are usedThe rest sit dormant, which is why nobody notices for months
- Someone downstream spots the anomalyOdd outbound traffic, a new dependency, a token used from a strange place
The last two steps explain why these attacks stay hidden for months. A criminal who steals ten thousand credit cards uses ten thousand credit cards. An attacker who owns ten thousand networks uses a handful and leaves the rest alone, because activity is what gets you caught.
Types of Supply Chain Attacks
The vectors differ in what the attacker touches and, more usefully, in who is capable of noticing.
| Type | What the attacker compromises | Who can realistically catch it |
|---|---|---|
| Software update | The vendor's build or release pipeline, so a signed update carries the payload | The vendor, then downstream network monitoring |
| Open source dependency | A package, or the account of the person who maintains it | Developers, through pinned versions and dependency review |
| Build and CI/CD | The pipeline itself: workflow files, runners, stored secrets | The engineering team reading its own pipeline logs |
| Browser and web script | A third-party script on a page you own, such as analytics or a payment form | The site owner, through content security policy and script inventory |
| Managed service provider | The remote monitoring tool an IT provider uses to administer every client | The provider, and clients who watch what their provider's account does |
| SaaS and connected apps | An application granted access to your hosted platform through a token | The customer, by auditing which applications hold which permissions |
| Hardware and firmware | The physical device or its firmware before it reaches the buyer | Almost nobody, which is why this one is rare and expensive |
| Data processor | A file transfer service, payroll bureau or billing provider holding your records | The processor, and the customer reading the notification letter |
Two rows matter most to readers who do not write software. The managed service provider row and the SaaS connected app row reach companies with no developers at all, and nobody inside the company has to install anything for either one to work.
What Are Some Famous Supply Chain Attacks?
Four cases carry most of what the category teaches, and all four have a primary government account rather than a vendor blog post behind them.
SolarWinds, 2020. An intelligence actor added a malicious version of the file solarwinds.orion.core.businesslayer.dll into the SolarWinds software lifecycle, and it was then signed by the legitimate SolarWinds code signing certificate, according to CISA's advisory. Five Orion platform versions carried the backdoor, CISA ordered federal civilian agencies to disconnect affected devices on December 13, 2020, and in April 2021 the US government attributed the activity to the Russian Foreign Intelligence Service. The detail most retellings drop sits in the same advisory: CISA said it had evidence of initial access vectors other than the Orion platform.
Kaseya, 2021. Ransomware operators reached managed service providers through a flaw in Kaseya's VSA remote monitoring product, and from those providers into the small businesses each one administered. CISA and the FBI published joint guidance for affected providers and their downstream customers on July 4, 2021, telling providers to enforce multi-factor authentication on every account they control and to put remote monitoring interfaces behind a VPN or firewall. This is the case that made the MSP route famous, and it is still the one small companies are most exposed to.
MOVEit, 2023. The CL0P group exploited a previously unknown SQL injection flaw, CVE-2023-34362, in Progress Software's MOVEit Transfer, then installed a web shell named LEMURLOOT to steal data from the databases underneath, per the CISA and FBI advisory. No malicious update was involved. One unknown flaw in one file transfer product exposed the records of everyone whose data passed through it, which is how a single vendor becomes a breach notification letter at every organization downstream of it.
XZ Utils, 2024. A contributor spent years earning maintainer trust on a compression library used across Linux distributions, then embedded malicious code in versions 5.6.0 and 5.6.1. CISA's alert on the compromise told developers and users to downgrade to an uncompromised version such as 5.4.6 Stable and hunt for malicious activity. It was caught before it reached most stable releases, and by luck rather than by any control designed to find it. That is not something to build a defense on.
- CISA orders federal agencies to disconnect SolarWinds Orion after a signed build is found to carry a backdoor
- CISA and the FBI publish guidance for managed service providers and their customers hit through Kaseya VSA
- CISA and the FBI advise on CL0P exploiting an unknown flaw in MOVEit Transfer to steal data at scale
- CISA reports malicious code embedded in XZ Utils 5.6.0 and 5.6.1, caught before it reached most stable releases
- CISA reports the self-replicating Shai-Hulud worm across more than 500 npm packages
- CISA reports two compromised axios releases carrying a malicious dependency and a remote access trojan
- CISA reports a poisoned Nx Console extension used to reach internal GitHub repositories
What Are Some Recent Supply Chain Attacks?
The last twelve months moved the attack into the package registries, where the barrier to entry is a stolen maintainer account rather than a nation-state budget.
The Shai-Hulud npm worm, September 2025. CISA reported that a self-replicating worm publicly known as Shai-Hulud compromised over 500 packages. It scanned each environment it landed in for GitHub personal access tokens and cloud keys for AWS, Google Cloud and Azure, then authenticated to npm as the compromised developers and published poisoned versions of their packages, which is what made it a worm rather than an incident. CISA's guidance was to pin packages to releases published before September 16, 2025, rotate every developer credential, and enforce phishing-resistant multi-factor authentication on developer accounts.
The axios compromise, March 2026. Axios is one of the most widely installed HTTP clients in JavaScript. On March 31, 2026, two releases, axios@1.14.1 and axios@0.30.4, were published with a malicious dependency called plain-crypto-js@4.2.1, which downloaded multi-stage payloads from attacker infrastructure and ended in a remote access trojan on the developer's machine. CISA's mitigations are unusually concrete and worth copying into any engineering handbook: set ignore-scripts=true in .npmrc so install scripts cannot run, set min-release-age=7 so nothing published in the last week can be installed, and mandate phishing-resistant multi-factor authentication on all developer accounts.
Nx Console and GitHub, May 2026. CISA reported that attackers used an earlier compromise of Nx developer systems to poison a VS Code extension, which reached a GitHub employee's device through the editor's automatic update mechanism and led to exfiltration of internal GitHub repositories. A separate campaign named Megalodon injected malicious GitHub Action workflows to harvest CI/CD secrets, cloud credentials and tokens. Read the chain again: a compromised developer tool compromised a platform hundreds of thousands of companies build on, and no perimeter appears anywhere in it.
Why Supply Chain Attacks Work
Because trust is transitive and audits are not. You checked your vendor. Your vendor did not audit the packages buried deep in its dependency tree, and neither did the maintainer of the one that matters, who works on it in the evenings for free.
Roughly half of breaches now involve somebody other than the organization whose name ends up in the headline. Read the two numbers together and the pattern is clear enough: attackers are going after exposed software that many companies run, rather than the passwords of one company at a time, and a vendor's file transfer appliance is both of those things at once.
The economics finish the argument. Compromising a mid-sized software company takes the same effort as compromising a mid-sized law firm, and returns access to every customer the software company has.
How to Prevent Supply Chain Attacks
Prevention splits cleanly into two lists, and most guidance on this topic fails by giving the developer list to a reader who buys software rather than writes it.
If you build software, the second list is where the last two years of incidents point. Pin dependencies to exact versions and commit the lock file. Turn off install scripts and set a minimum release age, as CISA recommended after the axios compromise. Rotate CI/CD secrets on a schedule and scope them to one repository. Review the extensions your engineers run with the same seriousness as the packages they import. And put regular scanning of your dependencies into the build rather than into a quarterly report.
The inventory question has a formal answer now. CISA, the NSA, the FBI and international partners published updated minimum elements for a software bill of materials on July 29, 2026, describing an SBOM as an ingredients list for software and a building block of supply chain risk management. Asking a vendor for one is now a reasonable request rather than an exotic one. Whether the vendor can produce a useful one tells you a great deal about how well it knows its own product.
The governance layer above all of this has a reference document: NIST's Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, SP 800-161 Revision 1, which sets out a multilevel approach putting supplier risk inside enterprise risk management rather than in a security silo. It is written for organizations with a formal risk management function, so a small company should take the structure and ignore the checklists.
How to Detect a Supply Chain Attack
Detection is genuinely hard, and pretending otherwise is how readers end up with false confidence. The malicious code is signed. The account is legitimate. The connection is one your own policy permits. Everything a control would normally flag has been made to look correct upstream.
What remains is behavior. A trusted component doing something it has never done before is the signal, and it only exists if you know what normal looked like.
The version available to a company without a security team is narrow but real. Turn on audit logging in every hosted platform, route the alerts somewhere a person looks, and subscribe to the security advisories of the vendors whose software touches your data. Most supply chain incidents reach their victims first as a vendor notification, so the detection you most need is somebody reading the email.
What to Do If a Supplier Is Breached
The notification arrives, it is vague, and the temptation is to wait for the next update. Do these things instead, in this order.
Key takeaways
- A supply chain attack compromises a supplier to reach the supplier's customers. The malicious code or access arrives through a trusted channel, signed and expected.
- The upstream half is the break-in at the vendor. The downstream half is the vendor delivering the payload to thousands of customers, usually automatically.
- Third parties were involved in 48 percent of breaches in the 2026 Verizon DBIR, up 60 percent in a year.
- The vector moved from vendor build servers to package registries and developer laptops, and small companies are downstream victims by design, usually through a managed service provider or a connected application.
- Prevention for buyers is an access inventory, least privilege, connected app audits and phishing-resistant MFA. Prevention for builders is pinned dependencies, disabled install scripts and scoped CI/CD secrets.
- Detection is behavioral. Trusted software reaching somewhere new, and vendor tokens used at strange hours, are the two signals that survive a signed payload.
Common questions
What is a supply chain attack in simple terms?
Someone breaks into a company you buy from, then uses that company's software or access to reach you. You never see an attack on your own systems, because the harmful thing arrives inside an update you installed on purpose.
Which one is an example of a supply chain attack?
SolarWinds is the standard example. Attackers added a backdoor to a network monitoring product's build, it was signed with the vendor's own certificate, and customers installed it as a routine update. The 2026 axios compromise is the same idea in a software package: two poisoned releases carrying a malicious dependency.
What is the difference between a supply chain attack and a third-party breach?
A third-party breach is any incident at a company holding your data, including one that ends there. A supply chain attack uses the third party as a route to reach you deliberately. Every supply chain attack is a third-party breach; not every third-party breach was aimed through the vendor at its customers.
Is a supply chain attack the same as a software supply chain attack?
A software supply chain attack is the subset that travels through code: updates, packages, build pipelines, extensions. The wider category also covers hardware and firmware tampered with before delivery, and service providers whose legitimate access is abused without any code being modified at all.
How common are supply chain attacks?
Common enough that a third party is now involved in 48 percent of breaches, according to the 2026 Verizon Data Breach Investigations Report, and that figure rose 60 percent in a single year. Software supply chain compromises specifically now appear in CISA alerts every few weeks rather than every few years.
Can a small business be hit by a supply chain attack?
Yes, usually as collateral rather than as a target. Two routes reach small companies: the managed IT provider whose remote monitoring tool administers every client at once, and a hosted platform where an employee authorized a third-party application with more access than anyone realized.
How do you prevent supply chain attacks?
You reduce them rather than prevent them. Inventory what each supplier can reach, cut that access to the minimum, audit connected applications on a schedule, require phishing-resistant multi-factor authentication on vendor and administrator accounts, and patch the appliances vendors put at your network edge.
What is an SBOM and do I need one?
A software bill of materials is an ingredients list for a piece of software, naming the components inside it. CISA and its partners published updated minimum elements in July 2026. If you buy software you do not need to produce one, but asking vendors for theirs tells you whether they could answer within a day when the next widely used package is poisoned.
Are open source packages safe to use?
They are as safe as commercial code and fail differently. The risk is not the license, it is that a widely installed package may be maintained by one unpaid person whose account is a single credential away from publishing to millions of projects. Pin versions, disable install scripts, and wait a week before adopting a new release.
How would I know if one of my suppliers had been breached?
Most companies find out because the supplier tells them, which is why someone has to be reading those notifications and subscribing to vendor security advisories. The detection you own is behavioral: audit logs in every hosted platform, alerts routed to a person, and a baseline of what each integration normally does.
On this page
- What Is a Supply Chain Attack?
- How Does a Supply Chain Attack Work?
- Types of Supply Chain Attacks
- What Are Some Famous Supply Chain Attacks?
- What Are Some Recent Supply Chain Attacks?
- Why Supply Chain Attacks Work
- How to Prevent Supply Chain Attacks
- How to Detect a Supply Chain Attack
- What to Do If a Supplier Is Breached
Daniel Reyes
Daniel Reyes is a CISSP who spent twelve years in security operations, most recently leading a detection and response team for a mid-sized healthcare group in Texas. He reviews every resource and breach report on Cyber Security Firms for technical accuracy before it publishes.
Most of the people he has trained arrived having been told too much: a dozen acronyms, six vendors, and no clear idea which risk was theirs. His approach is to explain what an attack actually does before naming the tool that stops it, on the basis that most breaches start with something a reader could have recognised.