Real-World Dependency Breakage Scenarios
Learning from history: How small dependency changes caused widespread outages, and what they teach us about building resilient systems.
Why Study Past Incidents?
Dependency incidents reveal systemic weaknesses in how the software industry manages its supply chain. Each incident, while painful, provides lessons that improve our practices. These case studies span different types of failures—from accidental breakage to intentional sabotage to security compromises.
The left-pad Incident
What Happened
Azer Koçulu, the author of over 250 npm packages, unpublished all of them after a dispute with npm Inc. over the package name "kik." One of those packages was left-pad—an 11-line function that pads strings with zeros or spaces.
Despite its triviality, left-pad was depended upon by thousands of packages, including Babel (the JavaScript compiler). When it disappeared, builds broke across the JavaScript ecosystem. React, Ember, Node itself—major projects suddenly couldn't build.
The Response
npm Inc. took the unprecedented step of un-unpublishing the package, restoring it without the author's consent. They also implemented policies preventing unpublishing of packages with significant dependents.
Key Lessons
- Micro-dependencies create macro-fragility: Depending on an 11-line package feels efficient but concentrates risk
- Transitive dependencies hide exposure: Most affected teams didn't knowingly depend on left-pad
- Registry policies matter: The ability of one person to break the ecosystem required governance changes
- Lock files help but don't solve: Pinned versions can't restore deleted packages
The colors.js & faker.js Sabotage
What Happened
Marak Squires, maintainer of the popular colors and faker npm packages, intentionally published versions containing an infinite loop that printed garbage output. His stated motivation was frustration that corporations were freely using his work without compensating him.
colors had 22 million weekly downloads. faker had 2.8 million. Applications using these packages began hanging or crashing with ANSI garbage output.
The Fallout
Both packages were quickly reverted, and npm locked the author's account. But the incident reignited debates about open source sustainability: Should volunteers be expected to maintain critical infrastructure for free?
Key Lessons
- Maintainer wellbeing is a supply chain risk: Burnout, frustration, or financial pressure can manifest as security incidents
- Version pinning protects against push attacks: Teams with locked versions weren't immediately affected
- Single-maintainer packages are single points of failure: No peer review or governance checks
- Organizations should support their dependencies: Through sponsorship, contribution, or at minimum gratitude
The ua-parser-js Compromise
What Happened
Attackers gained access to the npm account of the ua-parser-js maintainer and published three malicious versions (0.7.29, 0.8.0, 1.0.0). The malicious code included:
- A cryptocurrency miner that ran on infected machines
- A password-stealing trojan for Windows systems
With 7 million weekly downloads and over 1,000 dependent packages, exposure was massive. Amazon, Google, Facebook, Microsoft, Slack, and others were potentially affected.
Detection and Response
The attack was discovered by community members within hours. The maintainer regained access and published clean versions. npm removed the malicious versions and issued a security advisory.
Key Lessons
- Account security is supply chain security: npm accounts must use 2FA and strong credentials
- Popularity attracts attackers: High-download packages are high-value targets
- Community vigilance works: Rapid detection limited the blast radius
- Install scripts are risky: The malware used npm's postinstall script feature
Common Patterns and Prevention
Across these incidents, several patterns emerge:
Pattern: Single Points of Failure
One maintainer, one account, one package = concentrated risk.
Prevention: Prefer packages with multiple maintainers, active communities, and organizational backing.
Pattern: Transitive Exposure
Most affected teams didn't directly use the compromised package.
Prevention: Understand your full dependency tree, not just direct dependencies.
Pattern: Automatic Updates
Teams using version ranges or auto-merge bots ingested malicious versions immediately.
Prevention: Use lock files rigorously. Review updates before merging. Consider update cadences.
Pattern: Weak Account Security
Compromised maintainer credentials enabled several attacks.
Prevention: Require 2FA for publishing. Monitor for unusual publishing patterns.
Building Resilience
No defense is perfect, but layered protections reduce risk:
- • Lock file discipline: Commit lock files, review lock file changes
- • Update cadence: Batch updates weekly, not continuously, to allow community detection time
- • Dependency auditing: Run vulnerability scans in CI and monitor for new CVEs
- • Minimal dependencies: Evaluate whether each dependency provides value worth its risk
- • Private registry/proxy: Mirror critical packages locally; don't pull directly from public registries in production builds
- • Incident response plans: Know how you'll respond when (not if) a dependency is compromised