A supply chain attack is a cyberattack that targets an organization indirectly by compromising a trusted vendor, tool, library, or dependency in its software supply chain. Rather than attacking the target directly, adversaries insert malicious code or access into upstream components that the target organization then unknowingly installs and runs. According to NIST, supply chain attacks are "attacks that allow the adversary to utilize implants or other vulnerabilities inserted prior to installation in order to infiltrate data, or manipulate hardware, software, operating systems, peripherals, or services at any point during the lifecycle."
A supply chain attack targets you through something you trust. Instead of breaching your systems directly, attackers compromise a vendor, open-source library, build tool, or update mechanism that your software depends on. When you install a package, pull a dependency, or deploy an update, you're running their code, and if that code has been tampered with, the attacker is already inside.
The attack surface for supply chains is enormous. A typical modern application pulls in hundreds of direct dependencies and thousands of transitive ones. Developers don't audit every package they install, and attackers know it. Compromising one widely used library can reach thousands of downstream organizations simultaneously, which is exactly why supply chain attacks have become a preferred vector for sophisticated adversaries.
CISA and the FBI have identified software supply chain attacks as one of the most significant cyber threats facing organizations today, as they can enable attackers to gain access to vast amounts of sensitive information with a single, targeted compromise of a widely used software product or service.
Supply chain attacks take many forms. The common thread is compromising a trusted component to reach a broader set of targets.
Attackers publish malicious packages to public registries (npm, PyPI, RubyGems) with names that mimic legitimate internal packages or popular libraries. When a developer installs what they think is a trusted package, they're running attacker-controlled code. The 2024 software supply chain landscape saw over 512,000 malicious packages detected in a single year, a dramatic acceleration in the volume and sophistication of these attempts.
Attackers target the maintainers of widely used open-source projects through phishing, social engineering, or credential theft. Once they control a maintainer account, they can push malicious updates that propagate to every project using that dependency. The 2024 XZ Utils incident, documented by CISA, illustrated how a patient adversary spent nearly two years cultivating trust in an open-source project before inserting a backdoor that affected many Linux distributions.
Attackers target the infrastructure that builds, signs, or deploys software. Compromising a build server or CI/CD pipeline lets an attacker modify software binaries before they reach end users, without touching the source code at all. The 2020 SolarWinds attack, one of the most significant supply chain incidents on record, inserted malicious code into SolarWinds' build process, affecting roughly 18,000 customers who received the compromised Orion update.
Legitimate software vendors can themselves be compromised. Attackers who gain access to a vendor's update distribution system can push malicious updates to the vendor's entire customer base, turning the trust relationship between vendor and customer into a delivery mechanism for malware.
Software Composition Analysis (SCA) is the primary technical control for software supply chain risk. SCA tools inventory your dependencies, check them against vulnerability databases, and flag malicious or compromised packages. An SBOM provides the foundation: a complete inventory of every component in your software, including transitive dependencies several levels deep.
Neither SCA nor an SBOM prevents an attacker from compromising a package you haven't installed yet. But they give your team the visibility to know what's in your build, respond quickly when new compromises are disclosed, and demonstrate to auditors and customers that you have a managed, documented approach to supply chain risk.
Fencer's SCA scanning continuously monitors your connected repositories for dependency vulnerabilities and malicious packages, mapping findings to CVE IDs and providing prioritized remediation guidance. When a new supply chain compromise is disclosed, like a backdoored npm package or a newly flagged transitive dependency, Fencer surfaces affected components across your codebase rather than requiring your team to manually audit every project. Fencer also auto-generates SBOMs in CycloneDX and SPDX formats, giving you the inventory layer that makes rapid supply chain response possible.
A vulnerability is a flaw in software that an attacker can exploit. A supply chain attack is a delivery mechanism: the attacker compromises software or infrastructure that you already trust and use, so that the malicious code arrives through a legitimate channel (a package install, a software update, a CI/CD pipeline). The distinction matters because supply chain attacks can bypass traditional defenses. You're not being attacked at the perimeter; you're being attacked through the front door, via code your team already decided was safe to run.
If you're writing any code for production, you're using open-source packages, possibly without realizing it. Every framework, runtime, testing library, and build tool typically pulls in a dependency tree that numbers in the hundreds. Beyond direct code dependencies, supply chain risk also applies to your SaaS tools (what happens when a vendor's update pipeline is compromised?) and your CI/CD infrastructure. Assessing your actual exposure starts with understanding what's in your software, which is what SCA scanning and SBOM generation do.
XZ Utils was unusually sophisticated. The attacker spent nearly two years embedding themselves in the open-source project as a contributor before inserting the backdoor. Most supply chain attacks are far less patient: they rely on typosquatting (publishing a package with a name nearly identical to a popular one), compromised maintainer accounts, or injecting malicious code into an existing package. The common thread across all variants is exploiting trust. You thought the code was safe because it came from a source you trusted.
