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

Original Article ↗ Hacker News Discussion ↗

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.