What Is a Supply Chain Attack? How It Works and How to Stay Safe

A supply chain attack is a cyberattack that reaches its real target indirectly, by first compromising a trusted vendor, software dependency, build pipeline, or update mechanism that the target already relies on. Instead of breaching an organization's own defenses head-on, the attacker poisons something the organization installs, downloads, or updates willingly, then rides that trust straight through the front door.

The approach is attractive to attackers precisely because it scales. Compromise one widely used software update, open-source package, or hardware component, and every downstream customer who installs it becomes a potential victim, often without any sign that something is wrong. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) puts it plainly: these attacks "affect all users of the compromised software and can have widespread consequences for government, critical infrastructure, and private sector software customers."

What exactly counts as a supply chain attack

A supply chain attack targets the chain of suppliers, software components, and processes that a product or organization depends on, rather than the end target itself. The National Institute of Standards and Technology (NIST) frames the underlying problem as "the potential for harm or compromise arising from suppliers, their supply chains, their products, or their services," noting that the risk comes both from weaknesses in products moving through the chain and from weaknesses in the chain itself.

CISA's own definition is more specific to software: a software supply chain attack "occurs when a cyber threat actor infiltrates a software vendor's network and employs malicious code to compromise the software before the vendor sends it to their customers." The compromise can be present from the moment the software ships, or it can be introduced later through a routine patch or update, meaning the tampering happens before that patch ever reaches a customer's network.

What unites every variant is the indirection. The attacker does not need to beat an organization's firewall, endpoint detection, or security team. They only need to compromise something that organization already trusts enough to install without deep scrutiny.

How a supply chain attack actually works

Most supply chain attacks follow a two-stage pattern. In the first stage, the attacker breaches a supplier: a software vendor's build environment, a popular open-source package, a hardware manufacturer's production line, or a managed-service provider's platform. In the second stage, that compromised supplier becomes the delivery mechanism that reaches the real target, often dozens, thousands, or tens of thousands of downstream customers at once.

This is what makes supply chain attacks so efficient for sophisticated threat actors, including advanced persistent threat (APT) groups. CISA notes that compromising a trusted vendor lets an attacker bypass perimeter defenses like firewalls and border routers entirely, because the malicious code arrives disguised as something the victim already approved to run with elevated privileges. CISA also observes that these campaigns typically require strong technical skill and long-term commitment, which is why the most damaging examples are usually attributed to well-resourced, patient actors rather than opportunistic criminals.

Common supply chain attack vectors and defenses

Supply chain attacks take several distinct forms depending on where in the chain the attacker inserts themselves. The table below summarizes the main vectors alongside the primary defenses organizations use against each one.

Software dependency attacks: malicious npm and PyPI packages

Modern software is assembled, not written from scratch. A typical application pulls in dozens or hundreds of open-source packages, many of which pull in further nested, or "transitive," dependencies the development team never explicitly chose. That makes package registries a high-value target.

CISA documents a concrete case: in 2018, researchers found twelve malicious Python libraries uploaded to the official Python Package Index (PyPI). The attacker used typosquatting, naming the packages things like "diango," "djago," and "dajngo" to catch developers who mistyped the popular "django" library. The malicious packages mirrored the real library's functionality but added the ability to gain boot persistence and open a reverse shell on the victim's machine. The same dynamic applies to npm, the JavaScript package registry, where lookalike package names, compromised maintainer accounts, and malicious post-install scripts have been used to reach developers' machines and, from there, the applications and companies they build. Pandromeda has covered a related case in a recent npm trusted publishing flaw and how registries have started pushing back with tools like a package firewall that blocks malicious npm installs.

Because dependency trees are deep and often invisible to the teams that rely on them, a single poisoned package can quietly ride along into thousands of downstream projects before anyone notices.

Compromised build pipelines and code signing

Not every supply chain attack targets a public package registry. Some go after the infrastructure that builds and ships software in the first place: continuous integration and continuous delivery (CI/CD) pipelines, build servers, and the code-signing process that is supposed to prove software came from a trusted publisher untampered.

Code signing exists to validate the identity of a piece of code's author and confirm its integrity. CISA explains that attackers undermine this safeguard "by self-signing certificates, breaking signing systems, or exploiting misconfigured account access controls," which lets them impersonate a trusted vendor and slip malicious code into what looks like a routine, properly signed update. CISA specifically calls out APT41, a China-based threat actor, as a group that has routinely undermined code signing while conducting software supply chain compromises. A build pipeline that is less hardened than the production systems it ultimately deploys to is, in CISA's language, itself a weak link; an attacker who compromises the pipeline can insert malicious code before it is ever compiled, signed, or reviewed.

Hardware and firmware supply chain tampering

Supply chain attacks are not limited to software. CISA's own threat profile of the ICT supply chain lifecycle, which spans design, development, production, acquisition, distribution, and maintenance, documents hardware-level tampering as well. One example CISA cites: researchers at a major U.S. software company investigating counterfeit products found malware preinstalled on roughly 20 percent of devices tested, malware that had been installed after the devices left the factory but before they reached customers, during transport, distribution, or reseller handling.

Wikipedia's overview of supply chain attacks similarly distinguishes hardware supply chain attacks, where "attackers tamper with electronics during manufacturing or distribution, installing malware or hardware-based spying components," from software supply chain attacks that compromise a widely used component to inject code into everything built on top of it. Because hardware tampering happens physically and early in a product's life, it is often the hardest category of supply chain attack to detect after the fact.

Compromised software updates

The update channel is one of the most consequential places a supply chain attack can land, because updates are, by design, trusted and often applied automatically with elevated privileges. CISA describes hijacking updates as one of the three most common techniques: a threat actor infiltrates a vendor's network, then either inserts malware into an outgoing update or alters the update so the attacker gains control over the software's normal functioning.

CISA points to the 2017 NotPetya incident as an example of this technique in its own guidance: Russian hackers targeting Ukraine spread malware through tax accounting software popular in the country, and what became known as NotPetya ultimately caused major disruptions well beyond Ukraine, affecting international shipping, financial services, and healthcare organizations globally. The lesson CISA draws is that an update channel is only as trustworthy as the vendor's internal security, and customers downstream have little visibility into that security until something goes wrong.

A documented case: the SolarWinds Orion compromise

CISA's guidance on defending against software supply chain attacks walks through the SolarWinds Orion incident in detail as a representative case study. In December 2020, the cybersecurity firm FireEye discovered a backdoor, later named SUNBURST, inside the SolarWinds Orion IT management platform. Investigators determined that the threat actor had used a separate implant, called SUNSPOT, to access SolarWinds' build server and insert the SUNBURST backdoor into the software before it was signed and distributed.

The backdoor spread to SolarWinds customers through what looked like a routine software update. According to CISA, the threat actor then selected specific victim networks from among those initially compromised for further, more targeted action. CISA describes the actor as patient, methodical, and careful to maintain a light malware footprint using legitimate credentials where possible, which made the intrusion unusually difficult to detect. The compromise ultimately reached an estimated 18,000 organizations that had installed the affected Orion updates, giving the attacker a foothold on numerous government and private-sector networks, though CISA notes the threat actor used non-supply-chain techniques to reach some of its more targeted victims.

The SolarWinds case remains, in CISA's words, "a recent example of how effective a software supply chain attack can be" and illustrates why a single compromised vendor can create consequences far beyond that vendor's own customer list.

Why these attacks are so hard to catch

Two structural factors make organizations uniquely exposed to supply chain attacks, according to CISA. First, many third-party software products require privileged, elevated system access to function, from antivirus tools to IT management and remote access software, and customers often accept those elevated defaults without scrutinizing them further. Second, most third-party software maintains frequent, ongoing communication back to the vendor for updates and support, which gives an attacker who controls the vendor's side of that channel a direct, trusted path into the customer's environment.

Combine privileged access with routine, expected network traffic, and a compromised update can look, to most monitoring tools, exactly like a normal one. OWASP's current Top 10 risk list reinforces how broad the exposure has become, ranking "Software Supply Chain Failures" third among all web application security risks in its 2025 edition. OWASP's guidance lists specific warning signs: not tracking versions of components, including transitive dependencies; running unsupported or outdated libraries; lacking change management across repositories, artifact stores, and CI/CD tooling; and patching on a slow, infrequent cadence that leaves a long exposure window open.

How organizations defend against supply chain attacks

There is no single control that closes off supply chain risk, but a consistent set of practices shows up across CISA, NIST, and OWASP guidance.

Software bills of materials (SBOMs). CISA recommends requiring a software component inventory, commonly called a software bill of materials, that lists the components and third-party code inside delivered software. Paired with tools that check that inventory against known-vulnerability databases, an SBOM lets an organization quickly determine whether a newly disclosed flaw, or a newly discovered malicious package, actually affects something it has deployed.

Code signing and build integrity. Verifying signatures on updates and build artifacts, protecting signing keys with strict access controls, and tracking provenance through the build pipeline all make it harder for an attacker to slip unsigned or illegitimately signed code past an organization's defenses.

Dependency pinning and deliberate versioning. OWASP recommends choosing dependency versions intentionally rather than always pulling the newest release automatically, and testing updated libraries for compatibility and integrity before deploying them broadly. Pinning dependencies to specific, vetted versions limits the window in which a newly poisoned package release can reach production.

Package firewalls and registry controls. Registries and organizations increasingly screen incoming packages for known-malicious signatures, typosquatting patterns, and suspicious install scripts before developers can pull them, adding a filtering layer on top of the open registries themselves. This category of defense has developed quickly, as detailed in Pandromeda's coverage of how a package firewall blocks malicious npm installs before they reach a developer's machine.

Vendor risk management. CISA's broader recommendation is a formal cyber supply chain risk management (C-SCRM) program: know and manage critical suppliers, understand how deeply the organization's key processes depend on each one, and apply the same security requirements to vendors that the organization applies internally. Staged or canary rollouts of vendor updates, rather than deploying to every system at once, also limit the blast radius if a trusted update turns out to be compromised. These same hardening principles apply to the categories covered in Pandromeda's explainer on malware types and warning signs, since a supply chain attack is ultimately a delivery mechanism for malicious code.

What's next: bottom line

Supply chain attacks succeed by exploiting trust rather than breaking through it, which is why they remain one of the most consequential categories of cyberattack: a single compromised vendor, package, or build system can become the entry point for thousands of victims who did nothing wrong except install something they reasonably believed was safe. OWASP's decision to rank software supply chain failures third on its 2025 Top 10, and ENISA's earlier finding that such attacks were expected to multiply fourfold, both point in the same direction: the problem is not going away, and the 2020 SolarWinds Orion compromise will not be the last incident of its kind.

For organizations, the practical response is not a single tool but a layered discipline: know what is in your software through an SBOM, verify what you install through code signing and dependency pinning, filter what reaches your developers through package firewalls, and manage vendors as part of your own risk surface rather than someone else's problem. None of that eliminates supply chain risk entirely, but each layer narrows the window an attacker has to exploit before someone notices.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage