I like the idea of a cool down. But my next question is would this have been caught if no one updated? I know in practice not everyone would be on a cool down. But presumably this comprise was only found out because a lot of people did update.

> 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.)

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)?

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

Stop using Javascript. Or Typescript or whatever excuses they have for the fundamentally flawed language that should have been retired eons ago instead of trying to get it fixed. Javascript, its ecosystem has always been a pack of cards. Time and again it has been proven again. I think this is like the 3rd big attack in the last 30 days alone.

Update dependencies when you need something in them, not just because there's a new version available.

Isn’t the problem with a minimum age release that the opposite would also occur - a high priority fix of zero day under exploit wouldn’t be fixed and you could be compromised in the window?

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.

Regarding doing more than just a minimum release age: The tool I personally use is Aikido "safe-chain". It sets minimum release age, but also provides a wrapper for npm/uv/etc where upon trying to install anything it first checks each dependency for known or suspected vulnerabilities against an online commercial vulnerability database.

> ~/.config/uv/uv.toml > exclude-newer = "7 days"

Note the if you get

   failed to parse year in date "7 days": failed to parse "7 da" as year (a four digit integer): invalid digit, expected 0-9 but got

  uv self update

Never, ever type "npm -i". This advice has served me well for many years.

compartmentalize. I do development and anything finance / crypto related / sensitive on separate machines.

If you're brave you can run whonix.

The issue is developers who have publish access to popular packages - they really should be publishing and signing on a separate machine / environment.

Same with not doing any personal work on corporate machines (and having strict corp policy - vercel were weak here).

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.

I guess this is the case for new installs, but for existing dependencies can’t you simply pin them to a patch release, and point at the sha?

Renovate can do it as well

But how do you know which one is good? If foo package sends out an announcement that v1.4.3 was hacked, upgrade now to v1.4.4 and you're on v1.4.3, waiting a week seems like a bad idea. But if the hackers are the one sending the announcement, then you'd really want to wait the week!

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 (external, outside the language ecosystem) 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

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

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