A software supply chain attack is when an attacker compromises something your software depends on, such as an open-source package, a build tool, an artifact repository, or a vendor update, so that malicious code reaches you and your users through a channel you already trust. Instead of attacking you directly, the attacker poisons a component you pull in, turning your own build and update process into the delivery mechanism. That indirection is what makes these attacks so effective: the malicious code arrives signed, expected, and trusted.

Understanding what a software supply chain attack is matters because modern software is assembled, not written from scratch. A typical application pulls in hundreds of open-source dependencies, build plugins, and container images, and each one is a link an attacker can target. Compromise a widely used package or the repository that serves it, and a single intrusion can fan out to thousands of downstream organizations at once.

How does a software supply chain attack work?

By subverting a trusted link between you and the code you run. Attackers have several well-worn routes, and they share one trait: the victim installs or builds something that looks legitimate.

The artifact-repository route shows why these attacks are so damaging. When an attacker gains admin control of the repository that stores an organization's binaries and packages, they can replace or poison the artifacts that every build pulls from, so the compromise ships itself into production across the whole organization.

Why are these attacks so hard to stop?

Because they exploit trust that is fundamental to how software is built. You cannot realistically inspect every line of every dependency, and the whole point of a package manager or an internal repository is that you trust what it serves. The malicious code also arrives through legitimate channels, often correctly signed and expected, so signature checks and "is this the right package" checks pass. High-profile incidents across open-source registries and vendor updates have shown that a single compromised link can reach an enormous downstream population before anyone notices.

How do you defend against a software supply chain attack?

You cannot eliminate the risk, so the goal is to see your dependencies, verify what you pull, and contain the blast radius. The controls that actually help are concrete and align with CISA and NIST guidance.

Maintain a software bill of materials (SBOM) so you know every component you ship and can find an affected one fast. Vet dependencies against known-vulnerable and malicious package data before they enter your build, and pin and verify versions rather than always pulling the latest. Harden your build pipeline and artifact repository, since those are high-value targets, and configure them securely rather than on defaults. Apply least privilege so a compromised dependency or build step cannot reach everything, and monitor for the unexpected new package, the surprising outbound connection, or the admin action nobody made.

Frequently asked questions

What is the most famous supply chain attack? Incidents involving compromised vendor updates and poisoned open-source packages are the archetypes, and both show the same pattern: one trusted link compromised, many victims reached.

Is open source less secure? Not inherently, but its openness and reuse make popular packages high-value targets, so the risk is concentration, not open source itself.

What is an SBOM and does it help? A software bill of materials lists every component in your software. It is one of the highest-value controls, because when a dependency is found vulnerable you can immediately answer whether and where you use it.

Our read

A software supply chain attack weaponizes the trust that makes modern development fast, which is why you defend it with visibility and verification rather than with a hope that every dependency is clean. The practical posture is to inventory what you depend on, verify and fix what enters your build continuously, and treat your build pipeline and artifact repository as the crown-jewel targets they are. When most of your code is other people's code, knowing exactly what you run is the whole game.

Defensive guidance per CISA software supply chain resources and the NIST SSDF; vector taxonomy per OWASP. Sources linked above.

Related: Code security for SMBs: packages, APIs, and SBOMs and Find and fix security bugs in AI-generated code.