Pnpm has a new setting to stave off supply chain attacks

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.