I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't.
Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can work, 3 days is ok, 7 days is a bit of an overkill but works too)
How to set them up?
- use latest pnpm, they added 1 day cooldown by default https://pnpm.io/supply-chain-security
- or if you want a one click fix, use https://depsguard.com (cli that adds cooldowns + other recommended settings to npm, pnpm, yarn, bun, uv, dependabot and, I’m the maintainer)
- or use https://cooldowns.dev which is more focused on, well, cooldowns, with also a script to help set it up locally
All are open source / free.
If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack.
Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown, but each of them have a way to do so. In the past few weeks, while I don't have hard numbers, it seems more risk has come from Software Supply Chain attacks (malicious versions pushed) than from new zero day CVEs (even in the age of Mythos driven vulnerability discovery)
The idea that 7 days is overkill is crazy to me. Unless you need a specific new feature, you should usually be fine with a dependency version that was released months ago when starting a new project. Ditto for doing regular dep upgrades.
The only issue I see is responding to vulnerabilities, where you want to upgrade immediately. But I think in that case it's fine to require the developer to be explicit in the new version they want.
I agree, but in most recent cases a 1 day cooldown would have been enough.
I added a “how to bypass if you have to patch a zero day CVE” section to depsguard for all supported package managers.
Doesn’t that just move the problem 7 days down the road? I always assumed these kinds of things just burn themselves because someone gets infected and realizes, not that there is an army of people auditing the changes. If everyone cooldowns for 7 days, it just happens later?
A large portion of the time, the maintainer notices what happened a few hours later. Maybe they were asleep or off doing other things for a while, but they eventually come back. And these kinds of takeovers frequently aren't complete enough to cover their tracks.
So at the very least, adding a cooldown raises the difficulty of these attacks above that threshold.
> large portion of the time, the maintainer notices what happened a few hours later.
So add it at the package manager level instead of the user level then?
Would be bad for software/progress I guess but, got me thinking of if we had an expectation a dev would post an update checksum/hash, then follow it up a day later with the update itself...
(well maybe that leads to kidnappings idk)
edit - heh, sibling comment on package manager-level must be much smarter
I fail to see how this isn't a simple cool down with more steps. It doesn't seem to add anything to the security posture of the package/update
Nobody can expose themselves during the danger period
Dev enforces cooldown on users, not users deciding they want to be safer. Dev has extra step of ensuring they check their accounts every ~23hr indefinitely.
The simple cooldown scenario sees potentially thousands of downloads of a malicious package. The 24 hour developer delay scenario sees zero downloads during the same period.
> Would be bad for software/progress I guess but
We all need to slow down and get some perspective. “Progress” doesn’t mean “rush everything and do it now now now”. Advancements should be slow, methodical, considered. That’s a good thing, not a weakness.
:)
I like it. Well, it would be tough for everybody whenever a long-awaited feature arrived but was out of touch just behind the glass. Maybe will improve our delayed gratification appreciation!
These get detected almost immediately, and removed by npm within hours (axios, tanstack at least)
But who will detect them on day one once everyone ignores them for seven days?
These things are usually caught by tools specifically scanning npm or by the maintainers noticing their account is compromised, not by people auditing their own installed packages.
AI agents
There are some companies that specialize in detecting those, they do it for free (and get lots of marketing for it…)
Seems like you dropped something:
> Disclaimer: I maintain depsguard
Yikes. You are correct. Honest truth, I got a few downvotes (after a few more upvotes), thought this was the cause, but you’re right. Didn’t think that it matters much, I’ll add it back. Had no idea anyone noticed. Fair enough, thanks for keeping me honest.
Edit: added it back, inline.
Release escrow.
Teams should be able to say "at least N developers have to agree to a release before it happens." This should be a policy they can control and lock down with a non developer account.
Interesting idea, but there are so many cases of solo maintainers.
I think that npm can have its own cooldown and automated security scan. Socket.dev, StepSecurity both close a gap here by spending tokens to scan new popular packages. Whether they do it for marketing or out of the goodness of their heart, is irrelevant. They don’t charge for this service, and it’s something I’d expect Microsoft (who owns GitHub who owns npm) to do.
Heavy use of packages with solo maintainers is part of the problem here. Having multiple people looped in with proper governance doesn’t completely solve the issue but it makes it much harder to execute supply chain attacks.
It’s a bitter pill that we collectively don’t want to swallow, because it has a lot of negative connotations on our ability to deliver individual impact quickly.
Why not to create a separate distribution or channel (bleeding edge/stable/long term), like Linux distributions do?
I'm not so sure cooldown would be effective. Someone still has to override the cooldown to install the (potentially) questionable releases and discover problems. If no one does, you've only delayed the problems by 3/7/10/14 days.
After thinking more while typing this:
I think I'd agree we should indeed have a 10-day cooldown (i.e. don't install anything released in the last ten days.) I suppose I just don't think anyone should expect it to be the only mitigation.
I don't think anyone is saying cooldowns are the only thing you need - just that it's a 30sec change that should harden your code.
Also, most malicious versions seem to be detected by tools scanning new packages. People updating without cooldowns probably aren't manualy inspecting diffs. Giving tools more time to detect things seems pretty obviously good to me. Add to that maintainers reporting they've been pwned, and the floor for sneaking malicious code is much higher.
yes, props to pnpm for adding 1 day cooldown by default in v11.
NPM doesn’t make it easy to do cooldowns because their apis prevent it.
What do you mean? it's a local config in your .npmrc (min-release-age=days or minimum-release-age=minutes for pnpm compatibility, although pnpm has 1 day by default if you have the latest...)
Because the npm api doesn’t list package ages individually. This is why ncu cooldown fails. The workarounds suck. NPM should fix their listings so this becomes super easy to solve.
> Why cooldowns? Most npm (or pypi) compromises were taken down within hours,
But won't more people on cooldown mean less likelihood to catch the bug, thus extending the need for cooldowns?
These compromises are usually caught within hours by security researchers performing automated scanning of all published packages.
Except that exhaustively scanning for badness is provably impossible.
It's inevitable that a false negative will slip through one day, and when that happens, it will compromise everyone who installs it, no matter if on day one or day eight.
The idea isn't to comprehensively make malicious code impossible - the idea is to make it difficult to sneak in. If the NSA wants to spend 500 billion$ to compromise an NPM package, there's very little we can do. But if waiting 3 days for security scans catch even 10% of malicious packages, that 's 10% fewer incidents everyone else has to deal with. And now people pwning maintainers must be much more sophisticated so their attacks are entirely undetected for that period.
Makes sense.
I just hope that the companies who currently perform security scans for free/for exposure have a sustainable business model. Once such a company gains reputation, there's diminishing returns in headlines currency.
Honestly I'd prefer a system wide cooldown / age setting across all package managers and installers, with the option to poke holes / allow and also the option to deny / allow post installation runners. Something like a global asdf style installer that tracks and enforces these rules across all of it's managed package managers.
Something like a proxy that intercepts and depending on the source, is intelligent enough to examine the package for age. That would be cool. Already sounds like a cloud product you could sell.
This is like buying something from the grocery store and then waiting a week to eat it in case the FDA put out a warning about it.
More akin to letting astronauts stay in quarantine for a day in case they caught space bugs.
If every other week I would notice the FDA recalls a popular brand that would have taken over my brain and transmit my bank password and SSN to a stranger, I might prefer drinking week old milk.
Edit: not dismissing your analogy, it’s pretty much it.
If nobody drinks the milk until it’s a week old, that won’t help.
I do think cooldowns help, it’s more that this analogy doesn’t help.
The cow has to wake up and look at what milk she’s been putting out, and ideally the milk machine would use an early release channel so that some people will get the brain virus first.
Nobody has to drink it, just test it. The analogy is stupid, but it's more like if there was no FDA, you'd wait a week for food safe labs to test it, or you'd invest in your own testing.
The early release channel is sensible, but if you're a bad actor who's compromised a package you're not going to early release are you, you get it straight out there.
Yeah, I mean, there are companies out there, that (for the goodness of heart or marketing or both, and I prefer if they did it for marketing because that would make it sustainable) who drink the milk as soon as it hits the shelf, and immediately tells the grocery chain to remote it.
tl;dr - there is financial interest for some companies to not have cooldowns and detect poisoned milk immediately.
More accurate analogy is a food tester for a king I guess, if your replace king with "everyone", (and the food tester did it for inbound traffic for his product and didn't risk their life for it)
No it's not. That's a terrible analogy.
It's exactly the same. With both you have no idea if you'll be compromised once you pick up a new item from the store. With both you wait a week, in case the authorities issue a recall. With both you use it after that one week of waiting. Both are relying on luck to be safe.
The crazy thing is the risk from food is higher, we just don't really mind, because it's rare that we personally get affected
As much as I dislike this distribution model, this is a completely misapplied analogy. In npm with cooldowns case you "buy" a thing and get to use it instantly without any delay, it just won't get improved until a few days later - exactly as if the project you installed would use some timed staging channel for testing before making releases, except you're the one who controls the timing here.
If there was a good reason to believe the pop tarts you buy might unexpectedly be contaminated with dioxins, waiting a week would be prudent.