What Supply Chain Attacks Actually Are (And Why Your Dependencies Are the Risk)

The 2020 SolarWinds breach compromised 18,000 organizations — including parts of the U.S. federal government — without attacking any of them directly. The attackers inserted malicious code into a routine software update that SolarWinds distributed to its customers. Every organization that installed the update installed the backdoor. The vulnerability wasn't in any victim's system. It was in something they trusted.

That's a supply chain attack. And it's the category of security threat that most businesses have the least visibility into, because the attack surface isn't your infrastructure — it's everyone else's.

Why software dependencies are the attack surface

Modern software is assembled, not written from scratch. A typical web application depends on dozens of open-source packages. Each of those packages has its own dependencies. A medium-complexity project might have 500 to 1,000 transitive dependencies — code written by people you've never heard of, maintained by communities of varying size and rigor, published to repositories that are largely self-governing.

The security posture of that application is only as strong as the weakest package in that dependency tree. And most teams have no visibility into what those packages are actually doing. They install them because they appear in a tutorial, or because another developer recommended them, or because they solve a specific problem elegantly. The security properties of the package — whether it's been audited, whether it has known vulnerabilities, whether it was recently taken over by a new maintainer with different intentions — rarely get checked.

The Sonatype 2024 State of the Software Supply Chain report found a 156% increase in supply chain attacks over three years. The attack vector is increasingly popular precisely because it's effective: compromising one widely-used package gives attackers reach into every downstream project that depends on it.

How these attacks actually work

Malicious packages. An attacker publishes a new package with a name similar to a popular one — a technique called typosquatting. A developer mistyping the package name installs the malicious version. Or an attacker takes over a legitimate package whose original maintainer abandoned it, inserts malicious code, and publishes a new version. Every project that runs a routine dependency update installs the compromise.

Dependency confusion. Attackers publish a public package with the same name as a private internal package used by a specific organization. Package managers that check public repositories before private ones download the attacker's version instead. Alex Birsan's 2021 research demonstrated this worked against Apple, Microsoft, and other major technology companies.

Compromised build pipelines. The attack happens in the CI/CD pipeline rather than in the source code itself. The published artifact is clean; the build process that generates it is compromised. By the time the software reaches end users, it contains capabilities that weren't in the source repository.

What this means for businesses that aren't building software

The risk isn't limited to software development teams. Any business using third-party software, SaaS platforms, or managed services is exposed to supply chain risk in those vendors' stacks. When a vendor you trust is compromised, their access to your systems — your data, your integrations, your connected infrastructure — becomes the attacker's access.

This is one of the reasons security architecture decisions need to account for vendor access patterns, not just internal system design. The questions about what data a vendor can access, under what conditions, and what happens if that vendor is compromised are as important as the questions about your own security controls.

What responsible dependency management looks like

Scanning dependencies for known vulnerabilities (CVEs) is necessary but not sufficient. CVE databases capture known vulnerabilities; supply chain attacks often involve newly published malicious packages with no CVE yet. Effective supply chain security requires scanning for behavioral signals — packages that exfiltrate data, packages with recently changed ownership, packages with minimal adoption history that match the names of popular libraries.

The tooling for this has matured significantly. Tools like Vekt (kief.dev/vekt) scan package lockfiles across multiple ecosystems — npm, PyPI, Cargo, Go, Maven, and others — checking against both CVE/GHSA databases and malicious package advisories in real time. The 50-free-scans-per-day tier is enough for most small teams to validate dependencies before deployment without ongoing cost.

The practice of checking dependencies before deployment — not just at project setup, but on every update and as part of the CI pipeline — is the operational discipline that turns supply chain risk from a blind spot into a managed variable.

---

Related reading

• What Happens When You Get Hacked: A Realistic Timeline
• What Your Vendors' Security Posture Actually Means for You
• Building a Security Culture When Everyone Thinks It's IT's Job
• The Problem with Generic Tech Recommendations
• If the Recommendation Came Before the Questions, It's Not Advisory

Frequently asked questions about supply chain attacks

Are supply chain attacks only a risk for large companies?

No. Large companies are high-value targets, but the attack infrastructure targets developers and projects at every scale. A compromised npm package that gets installed in a small business's web project represents the same opportunity for the attacker as the same package installed in an enterprise codebase. The risk scales with the sensitivity of the data and systems accessible from the compromised environment, not with company size.

How do I know if my current dependencies are safe?

Run them through a dependency scanner against current CVE/GHSA databases and malicious package advisory sources. The results won't tell you everything — newly introduced malicious packages may not have advisories yet — but they identify known vulnerabilities and flagged packages. Checking lockfiles (package-lock.json, Cargo.lock, etc.) rather than just direct dependencies ensures transitive dependencies are included in the scan.

What's the difference between a CVE and a malicious package advisory?

A CVE (Common Vulnerabilities and Exposures) describes a known security flaw in legitimate software — a bug that can be exploited. A malicious package advisory (like those in the OSV-schema MAL-* namespace) describes a package that was intentionally created or modified to cause harm. Both represent risk, but they require different detection approaches: CVEs are identified by version and known vulnerability, malicious packages by behavioral analysis and publication patterns.

What should a non-technical business owner ask their development team about supply chain risk?

Three questions: Do we scan our dependencies for known vulnerabilities before deployment? Do we have a process for reviewing dependency updates before applying them? And do we know what data our third-party packages can access at runtime? If the answers are no, no, and no, that's a conversation worth having before an incident makes it urgent.