Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)?

Setting min-release-age=7 in .npmrc (needs npm 11.10+) would have protected the 334 unlucky people who downloaded the malicious @bitwarden/cli 2026.4.0, published ~19+ hours ago (see https://www.npmjs.com/package/@bitwarden/cli?activeTab=versi... and select "show deprecated versions").

Same story for the malicious axios (@1.14.1 and @0.30.4, removed within ~3h), ua-parser-js (hours), and node-ipc (days). Wouldn't have helped with event-stream (sat for 2+ months), but you can't win them all.

Some examples (hat tip to https://news.ycombinator.com/item?id=47513932):

  ~/.npmrc
  min-release-age=7 # days

  ~/Library/Preferences/pnpm/rc
  minimum-release-age=10080 # minutes

  ~/.bunfig.toml
  [install]
  minimumReleaseAge = 604800 # seconds

  # not related to npm, but while at it...
  ~/.config/uv/uv.toml
  exclude-newer = "7 days"

EDIT: looks like someone else had a similar idea: https://cooldowns.dev

Don't write anything backend or cli tool in NPM would be good start

> Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)?

Most of these attacks don't make it into the upstream source, so solutions[1] that build from source get you ~98% of the way there. If you can't get a from-source build vs. pulling directly from the registries, can reduce risk somewhat with a cooldown period.

For the long tail of stuff that makes it into GitHub, you need to do some combination of heuristics on the commits/maintainers and AI-driven analysis of the code change itself. Typically run that and then flag for human review.

[1] Here's the only one I know that builds everything from source: https://www.chainguard.dev/libraries

(Disclaimer: I work there.)

> Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)?

With pnpm, you can also use trustPolicy: no-downgrade, which prevents installing packages whose trust level has decreased since older releases (e.g. if a release was published with the npm cli after a previous release was published with the github OIDC flow).

Another one is to not run post-install scripts (which is the default with pnpm and configurable with npm).

These would catch most of the compromised packages, as most of them are published outside of the normal release workflow with stolen credentials, and are run from post-install scripts

The problem with cooldowns is that the more people use them, the less effective they become.

Cooldowns are passing the buck. These are all caught with security scanning tools, and AI is probably going to be better at this than people going forward, so just turn on the cooldowns server-side. Package updates go into a "quarantine" queue until they are scanned. Only after scanning do they go live.

I use a separate dev user account (on macOS) for package installations, VSCode extensions, coding agents and various other developer activities.

I know it's far from watertight (and it's useless if you're working with bitwarden itself), but I hope it blocks the low hanging fruit sort of attacks.

Maybe using a slower, stable package manager that still gets security/bug fixes, like nix.

Renovate can do it as well

Install tools using a package manager that performs builds as an unprivileged user account other than your own, sandboxes builds in a way that restricts network and filesystem access, and doesn't run let packages run arbitrary pre/post-install hooks by default.

Avoid software that tries to manage its own native dependencies or otherwise needs pre/post-install hooks to build.

If you do packaging work, try to build packages from source code fetched directly from source control rather than relying on release tarballs or other published release artifacts. These attacks are often more effective at hiding in release tarballs, NPM releases, Docker images, etc., than they are at hiding in Git history.

Learn how your tools actually build. Build your own containers.

Learn how your tools actually run. Write your own CI templates.

My team at work doesn't have super extreme or perfect security practices, but we try to be reasonably responsible. Just doing the things I outlined above has spared me from multiple supply chain attacks against tools that I use in the past few weeks.

Platform, DevEx, and AppSec teams are all positioned well to help with stuff like this so that it doesn't all fall on individual developers. They can:

  - write and distribute CI templates
  - run caches, proxies, and artifact repositories which might create room to
    - pull through packages on a delay
    - run automated scans on updates and flag packages for risks?
    - maybe block other package sources to help prevent devs from shooting themselves in the foot with misconfiguration
  - set up shared infrastructure for CI runners that
    - use such caches/repos/proxies by default
    - sandbox the network for build$
    - help replace or containerize or sandbox builds that currently only run on bare metal on some aging Jenkins box on bare metal
  - provide docs
    - on build sandboxing tools/standards/guidelines
    - on build guidelines surrounding build tools and their behaviours (e.g., npm ci vs npm install, package version locking and pinning standards)
  - promote packaging tools for development environments and artifact builds, e.g.,
    - promote deterministic tools like Nix
    - run build servers that push to internal artifact caches to address trust assumptions in community software distributions
    - figure out when/whether/how to delegate to vendors who do these things

Haha what if there's an urgent security fix in an updated package?