Abstract risks become real when you see what happens when things go wrong. This section collects case studies of supply chain failures—what happened, why it mattered, and what the industry learned.
I Was There
I've watched most of these unfold in real time. The panicked Slack messages. The "are we affected?" scramble. The 2 AM dependency audits. Reading about incidents in a textbook is one thing. Living through them teaches you differently. These aren't hypotheticals—they're why I check my dependencies.
The Classics¶
Early incidents that shaped how we think about dependency management.
-
left-pad (2016)
One developer unpublished an 11-line package. Builds broke across the internet. Lesson: transitive dependencies are invisible risk.
-
event-stream (2018)
A maintainer handed off a popular package to a helpful stranger who added malicious code. Lesson: trust doesn't transfer automatically.
-
colors.js (2022)
A frustrated maintainer intentionally corrupted their own packages. Lesson: maintainers are people with grievances.
The Vulnerabilities¶
Critical security incidents that demonstrated the stakes.
-
log4shell (2021)
A critical vulnerability in one of the most widely-used Java libraries. Trivial to exploit, devastating in impact. Lesson: you need to know what you're running.
-
xz utils (2024)
A multi-year social engineering campaign to backdoor SSH authentication. Lesson: even careful projects can be compromised.
-
SolarWinds (2020)
Attackers compromised a build system, inserting malware into legitimate updates. 18,000 organizations affected. Lesson: build systems are high-value targets.
Ongoing Threats¶
Attack patterns that continue to evolve.
-
Malicious packages with names similar to popular ones.
lodashvs1odash. Detection has improved but remains imperfect. -
Internal package names that match public registry names. Build systems pull from the wrong source.
Common Threads¶
Reading these cases, patterns emerge:
Trust is transitive. When you trust a dependency, you're trusting everyone who can push code to it—maintainers, CI systems, package registries. You're also trusting their dependencies, and their dependencies' dependencies.
Incentives matter. Maintainer burnout leads to abandoned projects or hostile takeovers. Lack of corporate support for open source isn't just unfair—it's a security risk.
Visibility saves you. Organizations that could answer "are we affected by log4shell?" quickly had SBOMs and vulnerability scanning. Those that couldn't were scrambling for weeks.
Attacks are sophisticated. The xz backdoor took years of social engineering. SolarWinds compromised a build system. These aren't script kiddies—they're patient, funded, and clever.
Defense is possible. Lock files, SBOMs, vulnerability scanning, update policies, code review—none of these are perfect, but together they reduce risk substantially.
Each case study includes sources. Where possible, we link to primary sources (CVE records, original disclosure posts, official advisories) rather than news coverage.