What Is a Supply Chain Attack?

Supply chain attack definition

A supply chain attack is an attack on a company through a supplier it already trusts. The attacker changes something that the company receives, and the company installs or runs it.

The attacker does not break into the target. The target brings the attack in. The supplier can be a software vendor, an open source maintainer, a code repository or a service provider. The change travels through the normal path, so firewalls and mail filters have nothing odd to stop.

The word "supply chain" covers every step between the people who write software and the people who run it. An attack can enter at any step. The result is the same: code that the receiver did not ask for runs with the trust of the real supplier.

This page covers the software kind. Physical supply chain attacks, such as tampered hardware, follow the same idea, and we do not cover them here.

What is a software supply chain attack?

A software supply chain attack hides malicious code in software, an update, a package or a build tool that people already trust. The next install or update then delivers the code.

The rest of the release is genuine. It works as before. That is why the attack is hard to see. A tool that lists changed files shows many changes in a normal release. The attack is one file, or one line, among them.

Attackers use four main entry points:

• The vendor's build or update system. The attacker alters the software before it ships. Every customer gets the change.
• An open source package. The attacker takes over a maintainer account or a publish token and releases a bad version.
• A build pipeline. The attacker alters a step that many projects use, such as a CI action.
• A release archive. The attacker adds code to the release file that does not appear in the public source repository.

Each entry point has a real case below. For the npm cases, read npm supply chain attacks.

Examples

Each example below links to a page in the Vigilance attack library. The library lists many more, sorted by year and by the way each attack arrived. Browse the full attack library.

• SolarWinds, 2020. Google Cloud reports that attackers trojanized SolarWinds Orion updates between March and May 2020. The SUNBURST backdoor waited 12 to 14 days before it acted. It ran commands and transferred files. See the SolarWinds Orion record.
• 3CX, 2023. Unit 42 reports that the 3CXDesktopApp installer itself carried malicious libraries. The malware delayed its first call out by one to four weeks. See the 3CX record.
• xz, 2024. A public disclosure on the oss-security list says versions 5.6.0 and 5.6.1 of xz carried a backdoor that intercepts SSH authentication. The code sat in the release tarballs and not in the git source. Andres Freund found it after he saw slow SSH logins. See the xz record.
• tj-actions/changed-files, 2025. Unit 42 reports that an attacker used a stolen token to push malicious code. The attacker moved existing tags to the bad commit, so every version tag pointed at it. The code dumped runner memory into workflow logs. See the tj-actions record.
• event-stream, 2018. Snyk reports that an attacker earned trust as a contributor and received publishing rights. The payload targeted one bitcoin wallet app. See the event-stream record.
• axios, 2026. Huntress reports that attackers published axios 1.14.1 and 0.30.4 with a new dependency. A postinstall hook deployed remote access trojans. See the axios record.
• litellm, 2026. BleepingComputer reports that litellm 1.82.7 and 1.82.8 on PyPI carried a credential stealer. See the litellm record.

Why they are hard to defend against

Supply chain attacks are hard to defend against because the attack arrives from a source that you trust. Your tools are built to stop strangers.

• The source is real. The update comes from the vendor's site or the package registry. Nothing about the delivery looks wrong.
• The change is small. One file in a large release holds the payload. In the xz case, the code was in the release archive and not in the repository, so a review of the repository finds nothing.
• The payload can wait. SUNBURST waited 12 to 14 days. The 3CX malware waited up to four weeks. A test on the day of install sees nothing.
• One break reaches many. A single compromise reaches every customer of the vendor. Datadog reports that Shai-Hulud 2.0 reached 796 unique npm packages.
• Known-bad lists come too late. A scanner that matches known flaws has nothing to match on a new attack. Someone must report it first.

A more useful question is what a new version can do that the old one cannot do. Vigilance asks that question. It compares the version you trust with the new one. It reports the file that gained a capability, such as a new network call or a new install script. It does not need to know the attack by name. It does not prove that an update is malicious. A person decides what to install.

Defense also needs steps outside the install. Pin your build steps, protect publish tokens and check each update. The nine controls list them. For tools, see software supply chain security tools.

What is supply chain compromise?

Supply chain compromise is the state that results from a successful supply chain attack: a trusted supplier or product now carries attacker code. The attack is the act. The compromise is the result.

The word names the poisoned release and the harm it can do. A company has a compromise when it runs the poisoned version, whether or not the payload has acted yet.

This matters for response. Removing the bad version is the first step. The second step is to assume the secrets on that machine are exposed, and rotate them. The ua-parser-js advisory says that any computer with an infected version installed must be considered fully compromised. See the ua-parser-js record.

Finally, check the machines you did not think of. IT installs most software on company machines, and a package scanner does not read those installers. Vigilance reads the files on the machine itself, whoever sent them.

FAQ

What are supply chain attacks?

Supply chain attacks are attacks that reach a company through a supplier it trusts. The attacker changes software, an update or a package, and the company installs it. See the attack library for real cases.

What is a supply chain compromise?

A supply chain compromise is the result of a successful supply chain attack. A trusted product or package now carries attacker code, and customers run it. Remove the bad version and rotate the secrets on every machine that ran it.