7 ms·

The "use cooldown" [0] blog post looks particularly relevant today. I'd argue automated dependency updates pose a greater risk than one-day exploits, though I

The "use cooldown" [0] blog post looks particularly relevant today. I'd argue automated dependency updates pose a greater risk than one-day exploits, though I don't have data to back that up. That's harder to undo a compromised package already in thousands of lock files, than to manually patch a already exploited vulnerability in your dependencies. [0] https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns https://blog.yossarian.net/2025/11/21/We-should-all-be-using...

jacquesm 11mo ago
But even then you are still depending on others to catch the bugs for you and it doesn't scale: if everybody did the cooldown thing you'd be right back where you started.
- woodruffw 11mo ago
  The assumption in the post is that scanners are effective at detecting attacks within the cooldown period, not that end-device exploitation is necessary for detection. (This may end up not being true, in which case a lot of people are paying security vendors a lot of money to essentially regurgitate vulnerability feeds at them.)
- falcor84 11mo ago
  I don't think that this Kantian argument is relevant in tech. We've had LTS versions of software for decades and it's not like every single person in the industry is just waiting for code to hit LTS before trying it. There are a lot of people and (mostly smaller) companies who pride themselves on being close to the "bleeding edge", where they're participating more fully in discovering issues and steering the direction.
- vintagedave 11mo ago
  That worried me too, a sort of inverse tragedy of the commons. I'll use a weeklong cooldown, _someone else_ will find the issue... Until no-one does, for a week. To stretch the original metaphor, instead of an overgrazed pasture, we grow a communally untended thicket which may or may not have snakes when we finally enter.
  - Aperocky 11mo ago
    That is statistically not possible, unless you are dealing with very small sample size. The "until no one does" is not something that can happen in something like npm ecosystem, or even among the specific user of "left-pad".
- nine_k 11mo ago
  To find a vulnerability, one does not necessarily deploy a vulnerable version to prod. It would be wise to run a separate CI job that tries to upgrade to the latest versions of everything, run tests, watch network traffic, and otherwise look for suspicions activity. This can be done relatively economically, and the responsibility could be reasonably distributed across the community of users.
- bootsmann 11mo ago
  It does scale against this form of attack. This attack propagates by injecting itself into the packages you host. If you pull only 7d after release you are infected 7d later. If your customers then also only pull 7d later they are pulling 14d after the attack has launched, giving defenders a much longer window by slowing down the propagation of the worm.
Ygg2 11mo ago
I don't buy this line of reasoning. There are zero/one day vulnerabilities that will get extra time to spread. Also, if everyone switches to the same cooldown, wouldn't this just postpone the discovery of future Shai-Huluds? I guess the latter point depends on how are Shai-Huluds detected. If they are discovered by downstreams of libraries, or worse users, then it will do nothing.
- __s 11mo ago
  There are companies like Helix Guard scanning registries. They advertise static analysis / LLM analysis, but honeypot instances can also install packages & detect certain files like cloud configs being accessed
  - Yokohiii 11mo ago
    But relying on the goodwill of commercial sec vendors is it's own infrastructure risk.
    - limagnolia 11mo ago
      So don't rely on their goodwill? Instead, pay them, under a contract.. or do it yourself.
    - perlgeek 11mo ago
      You can also pay a commercial sec vendor if you don't want to rely on their goodwill.
- hyperpape 11mo ago
  For zero/one days, the trick is that you'd pair dependency cooldowns with automatic scanning for vulnerable dependencies. And in the cases where you have vulnerable dependencies, you'd force update them before the cooldown period had expired, while leaving everything else you can in place.
- wavemode 11mo ago
  Your line of reasoning only makes sense if literally almost all developers in the world adopt cooldowns, and adopt the same cooldown. That would be a level of mass participation yet unseen by mankind (in anything, much less something as subjective as software development). I think we're fine.
Sammi 11mo ago
Pretty easy to do using npm-check-update: https://www.npmjs.com/package/npm-check-updates#cooldown https://www.npmjs.com/package/npm-check-updates#cooldown In one command: npx npm-check-updates -c 7
- tragiclos 11mo ago
  The docs list this caveat: > Note that previous stable versions will not be suggested. The package will be completely ignored if its latest published version is within the cooldown period. Seems like a big drawback to this approach.
  - nfriedly 11mo ago
    I could see it being a good feature. If there have been two versions published within the last week or two, then there are reasonable odds that the previous one had a bug.
    - hokkos 11mo ago
      some lib literally publish a new package at every PR merged, so multiple times a day.
plomme 11mo ago
Why not take it further and not update dependencies at all until you need to because of some missing feature or systems compatibility you need? If it works it works.
- skybrian 11mo ago
  The arguments for doing frequent releases partially apply to upgrading dependencies. Upgrading gets harder the longer you put it off. It’s better to do it on a regular schedule, so there are fewer changes at once and it preserves knowledge about how to do it. A cooldown is a good idea, though.
  - btown 11mo ago
    There's another variable, though, which is how valuable "engineering time now" is vs. "engineering time later." Certainly, having a regular/automated update schedule may take less clock time in total (due to preserved knowledge etc.), and incur less long-term risk, than deferring updates until a giant, risky multi-version multi-dependency bump months or years down the road. But if you have limited engineering resources (especially for a bootstrapped or cost-conscious company), or if the risks of outages now are much greater than the risks of outages later (say, once you're 5 years in and have much broader knowledge on your engineering team), then the calculus may very well shift towards freezing now, upgrading later. And in a world where supply chain attacks will get far more subtle than Shai-Hulud, especially with AI-generated payloads that can evolve as worms spread to avoid detection, and may not require build-time scripting but defer their behavior to when called by your code - macro-level slowness isn't necessarily a bad thing. (It should go without saying that if you choose to freeze things, you should subscribe to security notification services that can tell you when a security update does release for a core server-side library, particularly for things like SQL injection vulnerabilities, and that your team needs the discipline to prioritize these alerts.)
    - Vinnl 11mo ago
      At the same time, unplanned engineering time is almost always more expensive than planned engineering time. I'd rather have some regular, expected, upgrade work, than all of a sudden having to scramble because I need something at a moment when I didn't plan for that.
collinmanderson 11mo ago
For Python's uv, I think the closest thing to a cooldown is something like: uv lock --exclude-newer $(date --iso -d "24 hours ago") uv is considering a native relative date: https://github.com/astral-sh/uv/issues/14992 https://github.com/astral-sh/uv/issues/14992

jacquesm 11mo ago

But even then you are still depending on others to catch the bugs for you and it doesn't scale: if everybody did the cooldown thing you'd be right back where you started.

woodruffw 11mo ago
The assumption in the post is that scanners are effective at detecting attacks within the cooldown period, not that end-device exploitation is necessary for detection. (This may end up not being true, in which case a lot of people are paying security vendors a lot of money to essentially regurgitate vulnerability feeds at them.)
falcor84 11mo ago
I don't think that this Kantian argument is relevant in tech. We've had LTS versions of software for decades and it's not like every single person in the industry is just waiting for code to hit LTS before trying it. There are a lot of people and (mostly smaller) companies who pride themselves on being close to the "bleeding edge", where they're participating more fully in discovering issues and steering the direction.
vintagedave 11mo ago
That worried me too, a sort of inverse tragedy of the commons. I'll use a weeklong cooldown, _someone else_ will find the issue... Until no-one does, for a week. To stretch the original metaphor, instead of an overgrazed pasture, we grow a communally untended thicket which may or may not have snakes when we finally enter.
- Aperocky 11mo ago
  That is statistically not possible, unless you are dealing with very small sample size. The "until no one does" is not something that can happen in something like npm ecosystem, or even among the specific user of "left-pad".
nine_k 11mo ago
To find a vulnerability, one does not necessarily deploy a vulnerable version to prod. It would be wise to run a separate CI job that tries to upgrade to the latest versions of everything, run tests, watch network traffic, and otherwise look for suspicions activity. This can be done relatively economically, and the responsibility could be reasonably distributed across the community of users.
bootsmann 11mo ago
It does scale against this form of attack. This attack propagates by injecting itself into the packages you host. If you pull only 7d after release you are infected 7d later. If your customers then also only pull 7d later they are pulling 14d after the attack has launched, giving defenders a much longer window by slowing down the propagation of the worm.

Ygg2 11mo ago

I don't buy this line of reasoning. There are zero/one day vulnerabilities that will get extra time to spread. Also, if everyone switches to the same cooldown, wouldn't this just postpone the discovery of future Shai-Huluds? I guess the latter point depends on how are Shai-Huluds detected. If they are discovered by downstreams of libraries, or worse users, then it will do nothing.

__s 11mo ago
There are companies like Helix Guard scanning registries. They advertise static analysis / LLM analysis, but honeypot instances can also install packages & detect certain files like cloud configs being accessed
- Yokohiii 11mo ago
  But relying on the goodwill of commercial sec vendors is it's own infrastructure risk.
  - limagnolia 11mo ago
    So don't rely on their goodwill? Instead, pay them, under a contract.. or do it yourself.
  - perlgeek 11mo ago
    You can also pay a commercial sec vendor if you don't want to rely on their goodwill.
hyperpape 11mo ago
For zero/one days, the trick is that you'd pair dependency cooldowns with automatic scanning for vulnerable dependencies. And in the cases where you have vulnerable dependencies, you'd force update them before the cooldown period had expired, while leaving everything else you can in place.
wavemode 11mo ago
Your line of reasoning only makes sense if literally almost all developers in the world adopt cooldowns, and adopt the same cooldown. That would be a level of mass participation yet unseen by mankind (in anything, much less something as subjective as software development). I think we're fine.

Sammi 11mo ago

Pretty easy to do using npm-check-update: https://www.npmjs.com/package/npm-check-updates#cooldown https://www.npmjs.com/package/npm-check-updates#cooldown In one command: npx npm-check-updates -c 7

tragiclos 11mo ago
The docs list this caveat: > Note that previous stable versions will not be suggested. The package will be completely ignored if its latest published version is within the cooldown period. Seems like a big drawback to this approach.
- nfriedly 11mo ago
  I could see it being a good feature. If there have been two versions published within the last week or two, then there are reasonable odds that the previous one had a bug.
  - hokkos 11mo ago
    some lib literally publish a new package at every PR merged, so multiple times a day.

plomme 11mo ago

Why not take it further and not update dependencies at all until you need to because of some missing feature or systems compatibility you need? If it works it works.

skybrian 11mo ago
The arguments for doing frequent releases partially apply to upgrading dependencies. Upgrading gets harder the longer you put it off. It’s better to do it on a regular schedule, so there are fewer changes at once and it preserves knowledge about how to do it. A cooldown is a good idea, though.
- btown 11mo ago
  There's another variable, though, which is how valuable "engineering time now" is vs. "engineering time later." Certainly, having a regular/automated update schedule may take less clock time in total (due to preserved knowledge etc.), and incur less long-term risk, than deferring updates until a giant, risky multi-version multi-dependency bump months or years down the road. But if you have limited engineering resources (especially for a bootstrapped or cost-conscious company), or if the risks of outages now are much greater than the risks of outages later (say, once you're 5 years in and have much broader knowledge on your engineering team), then the calculus may very well shift towards freezing now, upgrading later. And in a world where supply chain attacks will get far more subtle than Shai-Hulud, especially with AI-generated payloads that can evolve as worms spread to avoid detection, and may not require build-time scripting but defer their behavior to when called by your code - macro-level slowness isn't necessarily a bad thing. (It should go without saying that if you choose to freeze things, you should subscribe to security notification services that can tell you when a security update does release for a core server-side library, particularly for things like SQL injection vulnerabilities, and that your team needs the discipline to prioritize these alerts.)
  - Vinnl 11mo ago
    At the same time, unplanned engineering time is almost always more expensive than planned engineering time. I'd rather have some regular, expected, upgrade work, than all of a sudden having to scramble because I need something at a moment when I didn't plan for that.

collinmanderson 11mo ago

For Python's uv, I think the closest thing to a cooldown is something like: uv lock --exclude-newer $(date --iso -d "24 hours ago") uv is considering a native relative date: https://github.com/astral-sh/uv/issues/14992 https://github.com/astral-sh/uv/issues/14992