Open Source
Security: Supply Chain Attacks
In 2024, one person nearly embedded a backdoor in xz-utils - a utility present on every Linux server. They spent 2 years pretending to be a good contributor. How does OSS defend against attacks like this?
- xz-utils backdoor 2024: discovered by accident from a 500ms SSH anomaly - could have affected millions of servers
- event-stream 2018: 2M+ weekly downloads, owner transferred the package to a stranger who added crypto-theft
- SolarWinds 2020: not OSS, but same supply chain attack - backdoor in a software update affected 18,000 organizations including US Treasury
- npm 2FA became mandatory for top-500 packages in 2022 - a direct response to account compromises
Supply chain attacks: how they work
A **supply chain attack** compromises not your code directly, but the dependencies you rely on. Instead of hacking the bank - hack the SDK the bank uses. The scale of impact: one compromised package → millions of affected projects.
**Why OSS is especially vulnerable:** 1) Maintainers are burned out and happy to hand off ownership. 2) Trust in long-term contributors. 3) Packages are installed automatically in CI. 4) `npm install` = executing arbitrary code (lifecycle scripts: postinstall).
What was the primary attack vector in the xz-utils backdoor of 2024?
Protecting your package: provenance, 2FA, lockfiles
Since 2023, npm supports **provenance** - a cryptographic proof that a package was built from exactly this repository in exactly this CI run. Verified via sigstore/OIDC, no additional keys required.
**Dependabot automatically creates PRs** when a new version of a dependency is available or a security advisory is published. Config: `.github/dependabot.yml`. For OSS projects this is standard - you don't track dependencies manually.
Why is `npm ci` safer than `npm install` in a CI pipeline?
Security advisories, CVEs and responsible disclosure
When a vulnerability is found in OSS, the standard process is **responsible disclosure**: privately notify the maintainer → give time to fix (typically 90 days) → publicly disclose. Full disclosure without warning is dangerous: it gives attackers a head start before a patch exists.
**As a maintainer:** never fix security bugs in public commits before the release. Experienced attackers monitor commit history of popular packages and exploit the window between the patch and the release.
You found an RCE vulnerability in a popular npm package. What is the right first step?
Key takeaways
- Supply chain attacks target your dependencies, not your code - one compromised package = millions of victims
- npm provenance cryptographically proves a package's origin via sigstore, no extra keys needed
- npm ci + lockfile = reproducible builds with no dependency confusion possible
- 2FA on npmjs.com is mandatory for any public package
- Responsible disclosure: private report → 90 days for a patch → coordinated public release
Related topics
Security influences funding - companies pay for secure dependency chains.
- Next lesson: OSS Funding — Tidelift pays maintainers for security SLAs
Вопросы для размышления
- Your package is used in 10,000 projects. An unknown developer contacts you and offers to help with maintenance. How do you vet them? What permissions do you grant first?
- A popular package is found to contain a malicious postinstall script. How do you quickly estimate the blast radius - how many projects already downloaded the infected version?