Oh no, not again a meditation on NPM supply chain attacks

Original Article ↗ Hacker News Discussion ↗

Repeated supply-chain attacks on the npm JavaScript ecosystem are prompting scrutiny of both its design and the broader economic model of open source. Commenters argue that permissive licensing, unpaid maintainers, and corporate reliance on vast dependency trees create systemic risk that Microsoft (as npm’s owner) and other large firms have little incentive to meaningfully reduce. Proposed mitigations range from stricter defaults (2FA, signing, cooldown periods, sandboxing, better tooling like pnpm/renovate) to cultural changes such as using fewer dependencies, pinning versions, and having companies fund or audit the projects they rely on.

Responsibility: Companies vs Volunteers

  • Strong disagreement over whether “the companies” or unpaid OSS maintainers are to blame.
  • One camp argues Fortune 500s freely exploit volunteer work, giving little back beyond demands.
  • Others counter that permissive licenses are effectively donations; using them as allowed isn’t “leeching,” and maintainers chose that model.
  • Some say commercial users should at least be prepared to maintain, fork, or pay for support if they rely on a dependency.

Corporate Incentives and Contribution

  • Several stories of companies informally promising OSS contributions for years but never funding them; OSS work is seen as “no time in the budget.”
  • Others note many OSS contributors are actually paid employees (e.g., major languages, foundations); but there’s a very long tail of small critical libraries run by volunteers.
  • Debate on whether corporate accounting and invoicing constraints really make funding volunteers “legally hard,” or if that’s just an excuse.

Licensing, Fairness, and “Leeches”

  • Dispute over whether it’s fair to morally criticize big companies that profit heavily from MIT/BSD code without giving back.
  • One side: permissive licensing implies you expect nothing; fairness arguments don’t change that.
  • Other side: legality ≠ fairness; people naturally see it as bad manners to profit massively from someone’s work with zero reciprocity.
  • Long subthread on non‑standard “not for big corps” licenses and whether they should still be called “open source” (strong pushback citing OSI definition).

NPM Culture and Ecosystem vs Others

  • Multiple comments: the real problem is JS/NPM culture—huge dependency trees, micropackages, aggressive auto‑upgrades, weak standard library.
  • Comparisons to Go, Maven, PyPI, crates.io, RubyGems:
    • Fewer tiny packages, better stdlibs, no postinstall, explicit upgrade commands, or signed packages (Ruby, PyPI).
    • Go’s “lowest compatible version” strategy praised for limiting surprise upgrades.
  • Some argue NPM is simply a bigger, juicier target; others say its design and defaults are uniquely dangerous.

Technical Root Causes and Platform Issues

  • Discussion on the web as a hostile app platform vs just “learn your tools better.”
  • UI components (date pickers, accessible widgets) cited as reasons for heavy dependency use.
  • Hardware security (TPM/Secure Enclave, secure boot) seen by some as unrelated; others say they’re mostly DRM tools, not a fix for NPM‑style attacks.

Mitigations and Best Practices (Today)

  • Practical suggestions:
    • Use pnpm (disables most postinstall scripts by default, minimum‑age for new releases).
    • Use Renovate (or similar) with “cooldown” windows before adopting new versions.
    • Pin exact versions, rely on lockfiles, use npm ci, avoid auto‑updates; some vendoring and manual diff review on updates.
    • Sandbox package managers (bubblewrap on Linux, sandbox‑exec on macOS) or develop inside VMs/containers with secrets kept outside.
    • Generate SBOMs and track with tools like OWASP Dependency-Track; use npm audit and external scanners (e.g., safe‑chain).
  • Recognized downsides: dialog fatigue, usability friction, impracticality of manually reviewing hundreds/thousands of transitive deps.

What NPM/Microsoft Could or Should Do

  • Strong criticism that package signing/verification was requested as early as 2013 and effectively ignored for years.
  • Others respond that NPM now has Trusted Publishing, provenance/attestations, and 2FA for top packages; claims that “nothing has been done” are disputed.
  • Proposed platform‑level measures:
    • Mandatory (or much broader) phishing‑resistant 2FA (hardware/WebAuthn) for popular packages, possibly with cooldowns after credential changes.
    • Require code signing and treat stolen tokens differently from stolen signing keys.
    • Built‑in malware scanning of new releases with human review queues and “cooldown” for high‑impact packages.
    • Better default token scoping, expiry, and tooling to derive minimal permissions.

Broader Security Model

  • Some argue endless arms‑race defenses are doomed; suggest “web of trust” style vouching, where third parties (including big companies) sign attestations that they’ve inspected specific versions and found no obvious malice.
  • Others emphasize sandboxing and OS‑level isolation as the long‑term way to make inevitable supply‑chain compromises less catastrophic.