Dependabot version updates introduce default package cooldown

>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

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

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.

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

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.

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.

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

> I’m convinced that updating so much more often is worse, not better.

The issue of cooldowns aside (which is about delaying updates, not reducing their frequency): you're going to have the same set of problems when you update, whether you do it frequently or infrequently. The difference is that if you update frequently, you'll have a smaller set of updates (so it's easier to debug) and you'll have more opportunity to report issues upstream and fix them in a timely fashion.

It's the same underlying problem as CI and build time. Most people abandoned the concept of projects that take so long to build you can only do testing once a week, because CI that runs on every PR provides a much better experience. This is the same lesson applied to updates.

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.

As a sysadmin I'm in the same boat. I've unfortunately never worked with security folks that seemed to have any sysadmin or dev experience. Whether or not this is universal, idk, and I have no idea what they are teaching in these security courses. But I'm tired of security teams telling me "you need to implement these 230 group policies this quarter" or whatever. They don't seem to grasp the externalities of a request like that and how much fucking work it is to vet, test, deploy, monitor, verify, etc. 80% of the time, they don't even know what they do or if it's even impactful for us.

I don't know if all ecosystems are as bad as node is, but the node ecosystem has terrible issue severity ranking which makes infosec squeamish for no reason.

Every week or so there's a new High+ "vulnerability" that gets published against our dependencies and I have to go look at it to confirm that it's yet another case of "it's possible for someone to give this dev-only tool a bad regex that would cause the test runner to OOM on that branch".

I feel the same. So so so many "regular expression denial-of-service" issues at my last job that just didn't seem serious or often reachable.

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.

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

Requires a GitHub security advisory and

> Only advisories reviewed by GitHub trigger alerts.

From https://docs.github.com/en/code-security/concepts/supply-cha...