>If everyone starts applying cooldowns, won't it postpone the problem?

There are still research firms who are actively and aggressively scanning new packages once they are pushed. For example socket.dev pulls new packages across ecosystems and performs automated analysis and runs it in a sandbox. We don't have to have them go boom in someone's production repos to find out there is a problem.

> But if everyone will be delaying updates, won't be there less chances to catch it in time?

No: the security assumption behind cooldowns rests on security scanning parties, not on innocent users being victimized. Three days is a short cooldown, but it should be a good enough lead for scanning parties.

> I'm not fully sure if it's possible to preventively scan all NPM packages or how much compute it would require.

It’s not that much data, particularly for parties that are directly financially incentivized to be the first to report malware.

Only a few of the recent supply chain attacks were discovered by users noticing weird behavior.

The majority were noticed by maintainers or third party groups noticing things like releases not tied to a source tag, many rapid releases, etc.

Cooldowns won’t stop everything, but it makes a malicious release significantly more likely to be noticed

Most of the malicious ones just curl something in a postinstall script, scanners already catch that. The sneaky ones don't look malicious until they run, and three days may not help.

The goal is to give time for automated scanners ran by cybersecurity companies to flag malware before it gets installed on real users.

I think the idea is that it gives a bit of time for the companies which run automated scans of new versions to run through and detect any issues with new versions before users install them en-mass.

Easy, then you just delay your project’s dependency updates just a little more than everyone else

The publishing topology is pretty fundamentally different: the entire power (and danger) of language package managers is that anybody can publish, not just a privileged few.

(This cuts both ways: I’d say that distribution package managers have learned valuable lessons about what users actually want from language package managers. Learning is a good thing.)

This comparison is tiresome. Distro package managers are curated, language package managers are not. They're serving completely different use cases; the former is the App Store, the latter is the web.

I'm in a similar camp, I dislike how often third-party package updates get pushed out, especially given the lack of serious inspection.

The reality is that each update is its own potential security issue and with supply chain attacks being all too frequent, it's not a panacea.

I’ve mainly handled it by pushing my team to be extremely conservative about what dependencies we take, especially if they pull in scads and scads of transitive dependencies.

This elegantly mitigates three problems in one go: update churn, dependency hell, and supply chain attack surface.

It also, frankly, tends to make the code easier to understand. I’m not a huge NIH person but I do have to say that a lot of packages these days tend to encourage ways of doing things that are unnecessarily complex. More than once I’ve replaced a dependency with homegrown code and reduced LOC in the same commit.

What would be a security measure that should only be selectively enforced?

You cannot call it a supply chain, if you have zero contractual relationships with the authors of the solutions you are using.

[1] https://news.ycombinator.com/item?id=44434355

What would a solution to this look like?

What would it take to not fear installing software? This isn't a npm problem, its a computing problem in general. Spaces like this are generally pretty against any sort of restrictions or limitations being put on computers under the name of safety (see Manifest v3)

No way to prevent this says only package manager where this regularly happens.

More like 3-per-day amirite