Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised):
I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) 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, disclaimer: 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 (described in detail in depsguard.com / cooldowns.dev) In the past few months, 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)
As an embedded dev who’s used to locking to toolchains and deps for years at a time, web dev is a culture shock in so many ways.
There's literally no excuse - I'm still baffled.
You mean there's no excuse for cooldowns? Yeah, there is. Security consultants have for years been saying that you need to always keep your dependencies updated. This is often parroted without any context of whether a package needs to be updated or not.
And what's a proper cooldown? 1 day? 3 days? 1 week? 1 month? If you have a vulnerability, now you're exposed during that cooldown period. There's no straight forward or easy answer here.
I am speaking from my own experience here with having to sit in during these discussions where security "advice" is provided to the development team without understanding what it entails or any tradeoffs. I found that keeping things relatively secure is hard work and needs to be a part of culture.
> but if you have a loved one who just needs a one click fix, these can likely save them from the next attack.
I'm not letting gam gams anywhere near that shit. She can continue writing her own apps in assembly language - it's good for her brain health!
A friend of mine has a github repo with references to how to set things up in sane and slightly more secure manner: https://github.com/jordanconway/package-manager-hardening
From that repo:
> Exact version pinning — specifying precise versions (1.0.0, ==1.0.0, =1.0.0, = 5.31.0) rather than ranges (^, ~>, >=) in package manifests. Ranges allow any version satisfying the constraint to be resolved at install time; exact pins mean only one version is ever valid.
My understanding is that pinning the dependency within the manifest isn't the mechanism that prevents the version from changing across installs -- it's the lockfile that accomplishes this.
Specifying precise versions is sufficient to ensure that the packages in your package.json are installed in the pinned versions. The problem solved by lockfiles is second, third and n-order dependencies. Just because you pinned precise versions does not mean react or vue or whatever random package you installed did as well.
That's where the lockfile comes in, it pins the dependencies of the dependencies.
The lockfile also handles the first-order dependencies, though. Pinning them in the manifest doesn't enforce this -- the lockfile does. And yes, I agree that the lockfile _also_ handles pinning dependencies-of-dependencies.
Lockfiles serve multiple purposes. For example, some include hashes so you aren't served altered packages from the package registry. I agree with you otherwise, though.
In most cases yes, but really depends on which package manager and what command, if you use npm ci, it uses the package-lock.json values, if you use npm install, it can use any levels of freedom in the package.json. So if you lock package.json you remove that degree of freedom. But sometimes you do want to be able to "recreate the lock file" since it does fix a CVE. Just with a lockdown, you'll get the legitimate patch vs an accidental malicious takeover.
Nice work!
Is there a sensible way to add a cooldown to Docker/Podman image pulling?
> 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.
This feels like a very very small group of people; and people who really could do with opening the file and adding the line.
I wish that was the case. Asking people to do something simple, doesn't matter how simple it is, depends on how simple they view it. Changing your own car's oil is actually not that hard, once you know how to do it, most people don't even try. Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the camera app in most providers. In any funnel, each step, no matter how easy, adds friction, remove the friction and you get bigger adoption.
So yes, everyone could open a file and edit it, also everyone could watch a youtube video on how to do X and yet choose to have someone else do it for them :)
> Changing your own car's oil is actually not that hard
It is. Changing oil requires a place where you have sufficient access to the vehicle to drain it; the right equipment; the right disposal solutions. Most people who have cars do not have that. And it takes significantly more time to change your own oil than to have someone else do it as part of other specialist maintenance.
> Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the camera app in most providers.
Exactly. Using a QR code app required specific knowledge of the app, an internet connection, some time, knowledge of how and when to use it, and something to use it with - the barrier of which surpassed the convenience gained from the QR code.
> So yes, everyone could open a file and edit it, also everyone could watch a youtube video on how to do X and yet choose to have someone else do it for them :)
I'm struggling to find a non-contrived group of people who:
- do not know how to open and edit a file on their system
- do use npm
- would find installing pnpm or running `sudo install -d -m 0755 /etc/apt/keyrings; curl -fsSL https://depsguard.com/apt/gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/depsguard.gpg; echo "deb [signed-by=/etc/apt/keyrings/depsguard.gpg] https://depsguard.com/apt stable main" | sudo tee /etc/apt/sources.list.d/depsguard.list >/dev/null; sudo apt update; sudo apt install depsguard` simpler
Of course, cooldowns.dev is a very long winded way of telling someone to run `npm config set min-release-age=3`, which is the simplest.
Changing oil requires
> a place where you have sufficient access to the vehicle to drain it
Probably the only valid argument for people who park on the street.
> the right equipment
One $5 wrench, one $10 filter wrench (optional). One set of ramps ($40), or jack stands ($30) if you already have a jack. One drain pan, $10 (or free if you're resourceful). Total cost max $65. Cheaper if you look for deals, buy used, borrow from a friend. If you can't afford $65 once to save money in the long run while owning a car, you probably should've bought a cheaper car.
> the right disposal solutions
Every oil change requires a jug of oil to be purchased. You can drain your used oil into this jug and then dispose of it along with your other household hazardous waste. This is not hard.
> Most people who have cars do not have that.
I might believe this for a place to do an oil change, maybe. I struggle to believe most, but I would believe many. Aside from that, if you don't have those things, you are choosing not to have them.
Which is kind of the point. None of these things are hard, at all. The majority of car owners 100 years ago could adjust their own timing, clean distributor points, replace belts, etc. because if they couldn't, they'd be calling for a tow truck every few hundred miles. Those are all harder, and things have only gotten easier with time. If you can't do them, you are choosing not to, because there's an even easier solution - spending more money and getting someone else to do it for you.
My favorite way to do it is in the auto parts store parking lot. They will help you cart your full drain pan back to their oil recycling receptacle and some will even prop the back door open for you to walk it straight there. The bonus being if you do happen to spill a bit you're not stuck having to power wash your own driveway. I've got a process down to where I can pull it off with one pair of nitrile gloves, one rag, and one trash bag, to keep any residue from the drain pan staining anything.
Good job, you forgot a new crush washer and now your oil pan will leak
In ~300k km worth of diy oil changes, I’ve yet to change a crush washer, and yet to have a drain plug leak.
I always replace them on friends’ Toyotas, because they seem more important, but on every car I’ve owned it hasn’t mattered. And if you take the least amount of effort to google “how to change oil on ________” (fill in the blank for your year, make, model), some forum or video will probably tell you exactly what steps to take, including whether or not changing a washer is necessary.
Costs me 15 cents per washer delivered, why bother risk it? The world doesn't need more cancerous used motor oil on the ground.
After downloading a service manual and doing many things myself it became very apparent that mechanics barely bother to do work the right way despite it coming at virtually zero extra effort.
It's quite rare to see them use a torque wrench on many bolts and if you ask them why "they know it by feel", cool, but why not use a torque wrench to the proper specs anyway? It's not any harder.
> One set of ramps ($40), or jack stands ($30)
Given the number of SUVs and trucks, many people don't even need these.
[dead]
That group of people is the loosely affiliated people called "vibe coders". Even to get them to install depsguard is a challenge. I just ask them to point Claude to depsguard or cooldowns and follow the instructions (to save the tokens, of course Claude can figure it what needs to be done on its own)
The issue is that Claude Code also will be super happy to npm install axios / tanstack etc unless you explicitly tell it to add cooldowns.
[flagged]
In what way is "edit your .npmrc" simple?!?
The JS ecosystem is really, really complicated, so any non-trivial app is going to use multiple bundlers, node runtimes, native runtimes, etc, etc, etc.
Every one of those has a different opinion about how to spell "cooldown".
On top of that, there's the bootstrapping issue of "I want to install the N pieces of ecosystem sprawl that read the .[p]npmrc that have the cooldown directive in them. How do I do that with a cooldown?" (Where N is unknowable, because of course it is.)
> The JS ecosystem is really, really complicated, so any non-trivial app is going to use multiple bundlers, node runtimes, native runtimes, etc, etc, etc.
This statement makes very little sense to me. I've worked on several of what are likely the largest JS monorepos in the world, and they all define a specific version of a specific runtime and package manager you should be using.
An extra $15 of labor is well worth the cost of not having to change my own oil. They will do it efficiently and won't break anything. The cost of messing up one time immediately cancels out a lifetime of DIY savings, and they are equipped to do it right.
theoretical question, do cooldowns still work if everyone has them?
Companies such as socket and safedep will still scan new packages and alert on malware (if they are able to detect it) so the packages are taken down before they pass your cool down
It’s kind of insane this doesn’t happen in the publish pipeline by default.
This is what serious software distribution platforms do. Developers may think that they are special and they would never install malware, but that's just not the case.
Less well maybe but yes. Security researchers still proactively test them, and the maintainer has a much better chance of catching it themselves.
I'd argue that we don't actually know if this is the case or not because we haven't yet gotten to that point. How do we know that security researchers won't just move to testing things later as well?
Because entire point of their work is to find the issues as fast as possible, and most importantly, before others.
You have a lot more faith than I do that companies paying security researchers will not try to cut corners by directing the researchers they employ or hire to look at stuff that they aren't even about to install.
No, it will stop working. The whole point of min age is letting someone else taste the food before you, so you are not poisoned. (except maybe scanners but they can't detect everything and the payloads will highly likely to remain dormant when it detected it's within a scanning env).
BTW it will only get much worse because popular AI coding harness (e.g. OpenCode/KiloCode) will just download random npm packages in the background without you knowing. And the devs don't care.
Kind of depends. If someone looses control of their credentials and notices someone using their account to post, it still might help.
> Hope it's ok I hijack this thread again about setting up cooldowns...
In addition to cooldowns it'd be nice if more package managers did triage between security fixes and normal releases (bug fix / performance improvement / new functionalities).
It's totally possible to say: "A security fix must only be a security fix and cannot ship any other feature".
Then, for a start, a security fix becomes easier to audit (both by security researchers and by the tools security researchers are using).
And then a cooldown can be used for the regular releases (e.g. non security-related bug fixes, perfs improvements, new functionalities, etc.) but no cooldown (or a much smaller countdown) for security fixes.
Something has to be said about a system like Debian where you can have an extremely stable server and you can configure unattended upgrades to only apply security fixes but nothing else.
Such new package releases are easier to audit by security researchers.
[dead]
> Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown,
by now, you should have received the feedback about why cooldowns don't make sense and why nobody is adopting them. look, you are writing an expression of the reason why right there.
I don't agree that nobody is adopting them. Can you please elaborate?
- Most companies I know have a 24 hours (at least) cooldown via their Artifactory / Nexus. They have ways to bypass it for urgent CVEs
- pnpm just adopted 24 hours cooldown as default, based on community feedback.
what is the difference between these two things from the point of view of how much work you have to do?
- checking every update of every dependency to see if is a relevant urgent security update
- checking every update of every dependency to see if it turns out to be a supply chain exploit
am i still checking every update of every dependency? there's no heuristic here. either you check them all, or you get randomly exploited - either by using known vulnerable software or from supply chain attacked software.
I believe the point is that if you delay patches until X days after release, usually someone will catch it and the maintainer or the package manager will pull the infected release. Thus, by you doing nothing and waiting X days, you protect yourself by never even getting the bad release. Then on the flip side, you just keep up with urgent security updates and push bad ones through faster after vetting them.
[dead]
It's a tradeoff, and I don't have hard data, but the cases where a reachable, exploitable, zero day CVE that requires an urgent immediate patch (usually unintentional vulnerability) vs complete dev machine / CI/CD takeover of a supply chain attack (malicious intent) - show that a 7 day cooldown (or even 24 hours) would be the safe choice. I should probably consider doing this research, didn't get to it yet.
How often do you update your lockfiles? Where ever I have worked, it's once a year or whenever we get a critical CVE (in which case we only update the offending package and it's dependencies if required). Unless an attack is happening every day the chances of getting hit is slim.
Exactly.