Pnpm has a new setting to stave off supply chain attacks

Original Article ↗ Hacker News Discussion ↗

JavaScript developers are experimenting with “delayed dependency updates,” such as pnpm’s new `minimumReleaseAge` setting, to slow the spread of supply-chain attacks that piggyback on freshly published npm packages. Commenters weigh how effective time-based delays really are compared to other safeguards like lockfiles, stricter install behavior, automated malware scanning, permission systems, and cryptographic verification, noting trade-offs between security, stability, and keeping up with bug fixes. Broader themes include the fragility of ecosystems with thousands of transitive dependencies, the limits of automated tools versus human review, and differing philosophies on how quickly production systems should take updates.

Effectiveness of delayed dependency updates

  • New minimumReleaseAge in pnpm is seen as a useful “soak period” so security scanners/researchers can catch malicious uploads before most users upgrade.
  • Some argue a universal delay might also slow rollout of fixes and simply shift the attack window, not remove it.
  • Others counter that recent npm attacks were detected within hours by researchers and security companies, so a days-long delay would have prevented many compromises.
  • There’s debate whether “everyone waiting” delays detection; several point out that canary users and automated scanners still install and analyze new releases immediately.

How supply-chain attacks are detected today

  • Disagreement over how effective automated scanners are: some say app‑sec companies constantly scan npm and have caught many attacks; others stress that humans typically notice issues first and tools only assist.
  • Consensus that malware detection is fundamentally hard; scanners mostly find obvious patterns, not arbitrary malicious logic.

npm, lockfiles, and update behavior

  • Confusion over whether npm install respects package-lock.json. Current behavior: it installs from the lockfile if lock and package.json are in sync; otherwise it updates the lockfile.
  • Many recommend npm ci in CI for deterministic builds and to avoid silent lockfile churn.
  • Lockfiles already store content hashes, but semver ranges in transitive dependencies still allow new versions to be pulled in when the lockfile is regenerated.

Ecosystem update culture and risk

  • JS and similar ecosystems rely heavily on semver and frequent updates; tools like Dependabot/Renovate encourage rapid patch/minor upgrades.
  • Some prefer aggressive auto‑updates for security; others advocate very slow, deliberate updates (months) and pinning everything.
  • There’s recognition that never updating creates large “dependency debt,” making future upgrades painful and sometimes blocking security fixes.

Alternative or complementary defenses

  • Proposals include:
    • Registry‑side or third‑party “delayed” registries and commercial delay policies.
    • Permission systems for packages (restricting network/file access, especially for install scripts).
    • Stronger use of hashes / provenance, or even hash‑based resolution.
    • Web‑of‑trust audit/review systems.
    • AI‑assisted code analysis, though many are skeptical it’s a silver bullet.

Implementation details & ecosystem adoption

  • Some complain the pnpm setting lacks explicit units and should perhaps use ISO‑8601 durations; others find that format ugly.
  • Questions about configuring it globally vs workspace files, and why it isn’t in package.json.
  • Similar features are appearing in other tools (uv, Yarn, potential Bun support, commercial proxies), suggesting a broader trend toward delayed/controlled upgrades.