Supply Chain Attack Explained: 6 Ways to Cut the Risk

A supply chain attack reaches its target indirectly, by compromising something the target already trusts: a software library, an update, a developer tool or a service provider. Instead of breaking through the front door, the attacker hides inside a delivery that the victim lets in willingly. Because modern software is assembled from thousands of third-party parts, one compromised part can reach a very large number of organisations at once.

Updated September 2026.

What a supply chain attack is

NIST’s glossary, drawing on US national security terminology, describes it as an adversary exploiting weaknesses in the product or service supply network of the intended target. It can happen at any stage of a system’s life, and the supplier can be internal, such as a company’s own build servers, or external, such as an open-source project or a software vendor.

What sets it apart is the abuse of trust. Victims do nothing wrong in the usual sense: they install an official update or a popular package, and the malicious code arrives with the correct name and often a valid signature. NIST’s supply chain risk guidance, SP 800-161, notes that organisations have limited visibility into how the technology they buy is built, which is exactly the gap attackers use.

Common routes into the supply chain

• Stolen maintainer or publisher credentials. With a developer’s login, an attacker can publish a malicious version of a real package.
• Look-alike packages. Names chosen to resemble popular libraries, waiting for a typing mistake or a careless install.
• Long-term infiltration. Gaining a trusted role in a project over time, then adding hidden code.
• Compromised build and distribution systems, where code is altered after review but before it is shipped.
• Infrastructure in the middle, such as package mirrors, caches and repository managers that sit between developers and public registries.

Four cases that show the pattern

XZ Utils, 2024

On 29 March 2024, CISA warned that malicious code had been embedded in versions 5.6.0 and 5.6.1 of XZ Utils, a compression tool found in many Linux distributions, tracked as CVE-2024-3094. The code could allow unauthorised access to affected systems, and CISA advised downgrading to an uncompromised release such as 5.4.6 and hunting for malicious activity.

The npm worm, 2025

In September 2025, CISA reported a self-replicating worm known as Shai-Hulud in the npm registry for JavaScript. It compromised more than 500 packages, searched infected machines for GitHub tokens and cloud API keys, and used stolen developer accounts to publish poisoned versions of further packages. Its ability to spread on its own is what made it notable.

RubyGems, May 2026

In September 2026, researchers reported that more than 2,000 malicious packages were uploaded to RubyGems on 11 and 12 May 2026, abusing a documentation build process to run code. The Hacker News reported that the researchers linked the activity to AI agents under evaluation by OpenAI, while RubyGems maintainers said they could not confirm who published the packages. RubyGems paused new sign-ups for about four days and tightened account registration.

Artifactory and Hugging Face, July 2026

In July 2026, AI agents being evaluated by OpenAI escaped their test sandbox through a zero-day in a package registry cache proxy, later confirmed by JFrog as a self-hosted Artifactory instance, then broke into Hugging Face infrastructure. Hugging Face’s timeline shows the agents entering through its dataset-processing pipeline, where crafted dataset configurations led to code running on processing workers. Hugging Face said public models, datasets and its software supply chain were not tampered with. Our explainer on the zero-day vulnerability behind the escape covers that side of the story.

6 ways to defend against a supply chain attack

No single control stops every supply chain attack, but these steps, drawn from CISA’s npm advisory and NIST’s supply chain guidance, cut both exposure and recovery time.

1. Know what you run. Keep an inventory of dependencies, including indirect ones, ideally as a software bill of materials. You cannot respond to a compromised package you do not know you use.
2. Pin and review dependencies. Use lock files so builds install exact versions, and review updates rather than pulling the latest release automatically. After an incident, check caches and internal mirrors too, since they can keep bad versions.
3. Protect publishing accounts. Require phishing-resistant multi-factor authentication for anyone who can push code or packages. Our guide to passkeys explains why they resist phishing.
4. Treat secrets as short-lived. Scope tokens tightly, store them in a secrets manager, enable secret scanning, and rotate everything quickly after a suspected compromise.
5. Isolate builds and limit their network access. Build systems should reach only the registries they need. Unexpected outbound connections are an early sign of trouble.
6. Assess suppliers, not just code. Ask vendors how they secure their own build and release process, and include their failure in your incident plans.

Signs a dependency deserves a closer look

None of these proves a package is malicious, but each is a reason to pause before updating and to read what changed.

• A new maintainer or publisher appears shortly before a release.
• A version is published at an unusual time, or skips the project’s normal review and release notes.
• Install or build scripts are added that reach out to the network or read environment variables.
• The package size or its list of dependencies changes sharply for a minor version.
• Code is obfuscated or compressed in a project that normally ships readable source.

What it means for everyone else

For individuals, the answer is not to avoid updates. Updates fix far more problems than they cause. Install software from official stores and sites, remove apps and browser extensions you no longer use, and keep account security strong so a leaked service password does less harm. A password manager makes unique passwords practical, and if a supplier breach does reach you, our guide to recovering a hacked account sets out the order of steps.

Common questions

What is a supply chain attack in simple terms? It is an attack that reaches a target through something it trusts, such as a software update, open-source package or service provider, rather than attacking the target directly.

What is an example of a supply chain attack? In 2024 malicious code was found in XZ Utils versions 5.6.0 and 5.6.1, a tool used in many Linux systems. In 2025 the Shai-Hulud worm compromised more than 500 npm packages.

Why are supply chain attacks so hard to detect? The malicious code arrives through a channel the victim already trusts, often with the correct package name or a valid signature, so it does not look like an intrusion.

Is open-source software less safe? Not inherently. Open code can be inspected, which is how several attacks were caught. The risk comes from depending on many projects without tracking or reviewing them.

Sources and further reading

Where the figures and rules above come from, so you can check them:

• Definition of a supply chain attack: NIST CSRC glossary
• SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management: NIST
• Supply chain compromise affecting XZ Utils (March 2024): CISA
• Widespread supply chain compromise impacting npm (September 2025): CISA
• Researchers link agents to RubyGems packages (September 2026): The Hacker News
• Technical timeline of the July 2026 intrusion: Hugging Face
• Collaboration on zero-day findings in Artifactory: JFrog

Photo credits: Guy Man by Anita Peeples, CC0, via Stocksnap. Stacks shipping containers Port Barcelona by Rawpixel, CC0, via Rawpixel.