Real-World Dependency Breakage Scenarios
Learning from history: How small dependency changes caused outages, and what they teach us about building resilient systems.
Why Study Past Incidents?
Dependency incidents reveal systemic weaknesses in software supply chains. Each incident provides lessons that improve our engineering practices.
The left-pad Incident
What Happened
An author unpublished left-pad—an 11-line function. Despite its triviality, it was depended upon by thousands of packages. Builds broke globally across the JavaScript ecosystem.
Key Lessons
- Micro-dependencies create macro-fragility: Depending on trivial packages concentrates risk.
- Transitive dependencies hide exposure: Most affected teams didn't know they depended on it.
The colors.js & faker.js Sabotage
What Happened
A maintainer intentionally sabotaged his own packages (25M+ weekly downloads) to protest corporate use without compensation. Applications began hanging with ANSI garbage output.
Key Lessons
- Maintainer wellbeing is a risk: Burnout or frustration can manifest as security incidents.
- Version pinning protects: Teams with locked versions were not immediately affected.
Common Patterns
Single Points of Failure
One maintainer, one account, one package = concentrated risk. Prefer packages with multiple maintainers.
Automatic Updates
Teams using auto-merge bots ingested malicious versions immediately. Use lock files and review updates.
Building Resilience
- • Lock file discipline: Commit lock files, review changes.
- • Update cadence: Batch updates weekly to allow community detection time.
- • Dependency auditing: Run vulnerability scans in CI and monitor CVEs.