We should all be using dependency cooldowns • Hacker News Board

Re: We should all be using dependency cooldowns

#231

Post by iainmerrick » Sat, Nov 22, 2025, 12:41 PM UTC

dap wrote: post #86

embedding-shape wrote: post #46

Earlier quoted context omitted.

> for critical vulnerabilities to assess whether your product is affect by it. Only then do you need to update that specific dependency right away. This is indeed what's missing from the ecosystem at large. People seem to be under the impression that if a new release of software/library/OS/application is released, you need to move to it today. They don't seem to actually look through the changes, only doing that if a…

At my last job, we only updated dependencies when there was a compelling reason. It was awful. What would happen from time to time was that an important reason did come up, but the team was now many releases behind. Whoever was unlucky enough to sign up for the project that needed the updated dependency now had to do all those updates of the dependency, including figuring out how they affected a bunch of software tha…

Yes, I’ve had exactly the same experience. Once you get off the dependency train, it’s almost impossible to get back on.

I don’t think this is specific to any one language or environment, it just gets more difficult the larger your project is and the longer you go without updating dependencies.

I’ve experienced this with NPM projects, with Android projects, and with C++ (neglecting to merge upstream changes from a private fork).

It does seem likely that dynamic languages make this problem worse, but I don’t think very strict statically typed languages completely avoid it.

Re: We should all be using dependency cooldowns

#232

Post by zdc1 » Sat, Nov 22, 2025, 12:42 PM UTC

lock1 wrote: post #107

dap wrote: post #86

Earlier quoted context omitted.

At my last job, we only updated dependencies when there was a compelling reason. It was awful. What would happen from time to time was that an important reason did come up, but the team was now many releases behind. Whoever was unlucky enough to sign up for the project that needed the updated dependency now had to do all those updates of the dependency, including figuring out how they affected a bunch of software tha…

I think it also depends on the community as well. Last time I touched Node.js and Javascript-related things, every time I tried to update something, it practically guaranteed something would explode for no reason. While my recent legacy Java project migration from JDK 8 -> 21 & a ton of dependency upgrades has been a pretty smooth experience so far.

Yeah, the JavaScript/Node.js ecosystem is pain. Lots of tooling (ORMs, queue/workflow frameworks, templating) is new-ish or quickly changing. I've also had minor updates cause breakages; semver is best-effort at best.

I don't like Java but sometimes I envy their ecosystem.

Re: We should all be using dependency cooldowns

#233

Post by jbkgujklgui » Sat, Nov 22, 2025, 1:20 PM UTC

duped wrote: post #44

layer8 wrote: post #20

People in this thread are worried that they are significantly vulnerable if they don't update right away. However, this is mostly not an issue in practice. A lot of software doesn't have continuous deployment, but instead has customer-side deployment of new releases, which follow a slower rhythm of several weeks or months, barring emergencies. They are fine. Most vulnerabilities that aren't supply-chain attacks are o…

A million times this. You update a dependency when there are bug fixes or features that you need (and this includes patching vulnerabilities!). Those situations are rare. Otherwise you're just introducing risk into your system - and not that you're going to be caught in some dragnet supply chain attack, but that some dependency broke something you relied on by accident. Dependencies are good. Churn is bad.

Vulnerabilities are not rare, the two most popular programming languages, javascript (node) and python, have 1000+ CVEs in their official docker images. I.e. in practice useless and shouldn't be used by anyone for anything.

Re: We should all be using dependency cooldowns

#234

Post by [deleted] » Sat, Nov 22, 2025, 1:21 PM UTC

BrenBarn wrote: post #130

bumblehean wrote: post #122

Earlier quoted context omitted.

>The thing to do is to monitor your dependencies and their published vulnerabilities, and for critical vulnerabilities to assess whether your product is affect by it. Only then do you need to update that specific dependency right away. The practical problem with this is that many large organizations have a security/infosec team that mandates a "zero CVE" posture for all software. Where I work, if our infosec team's s…

> The practical problem with this is that many large organizations have a security/infosec team that mandates a "zero CVE" posture for all software. The solution is to fire those teams.

[deleted]

Re: We should all be using dependency cooldowns

#235

Post by chuckadams » Sat, Nov 22, 2025, 1:32 PM UTC

Jweb_Guru wrote: post #221

torginus wrote: post #168

I just had a thought about dependency chain attacks - has there been any example where instead of overtly compromising the code, they injected an exploitable bug? Though I guess it'd be hard to prove intent in this case.

These are just backdoors as a vulnerability class. It does happen occasionally even in high quality widely used libraries, but it's very rare and usually quite sophisticated (e.g. https://en.wikipedia.org/wiki/XZ_Utils_backdoor in 2024). A lot of these attacks, even when highly sophisticated, only really work when the attack payload can be hidden in a binary--it's very very hard to insert a useful backdoor into the s…

It's also worth noting that the xz exploit didn't even live in the xz source, it was added to the source by the attacker before uploading it to the package build farms. With most of the current package repositories, there's not even an expectation that the bundles you get are derived from a particular tag or commit hash, let alone a detailed chain of custody. I remember RPM in the old days made a big deal out of "pristine sources" to which patches would be applied, but it still has no way to prove or enforce that claim.

Re: We should all be using dependency cooldowns

#236

Post by [deleted] » Sat, Nov 22, 2025, 1:38 PM UTC

jhatemyjob wrote: post #80

This is a decent approach, another approach is to vendor your dependencies and don't update them unless absolutely necessary. The only thing you'd need to react to is major security vulnerabilities.

[deleted]

Re: We should all be using dependency cooldowns

#237

Post by [deleted] » Sat, Nov 22, 2025, 1:41 PM UTC

smaudet wrote: post #21

jcalvinowens wrote: post #13

Earlier quoted context omitted.

I upgrade all dependencies every time I deploy anything. If you don't, a zero day is going to bite you in the ass: that's the world we now live in. If upgrading like that scares you, your automated testing isn't good enough. On average, the most bug free Linux experience is to run the latest version of everything. I wasted much more time backporting bugfixes before I started doing that, than I have spent on new bugs…

> zero day is going to bite you in the ass Maybe your codebase is truly filled with code that is that riddled with flaws, but: 1) If so, updating will not save you from zero days, only from whatever bugs the developers have found. 2) Most updates are not zero day patches. They are as likely to (unintentionally) introduce zero days as they are to patch them. 3) In the case where a real issue is found, I can't imagine…

[deleted]

Re: We should all be using dependency cooldowns

#238

Post by m000 » Sat, Nov 22, 2025, 1:42 PM UTC

Isn't the title kind of self-conflicting? Dependency cooldowns work because not everybody is using them. The more people start using dependency cooldowns, the less effective they become.

Re: We should all be using dependency cooldowns

#239

Post by chuckadams » Sat, Nov 22, 2025, 1:45 PM UTC

wrs wrote: post #17

jerlam wrote: post #11

Earlier quoted context omitted.

Your CI/CD might be setup to upgrade all your dependencies on every build.

I’ve seen a lot of CI/CD setups and I’ve never seen that. If that were common practice, it would certainly simplify the package manager, since there would be no need for lockfiles!

I do see some CI running without lockfiles, and there's still a contingent that believes that libraries should never commit their lockfiles. It's a reasonably good idea to _test_ a configuration without the lockfile, since any user of your dependency is using _their_ lockfile that their local solver came up with, not yours, but this ought to be something you'd do alongside the tests using the lockfile. So locking down the CI environment is a good idea for that and many other reasons.

Realistically, no one does full side-by-side tests with and without lockfiles, but it's a good idea to at least do a smoke test or two that way.

Re: We should all be using dependency cooldowns

#240

Post by macintux » Sat, Nov 22, 2025, 1:57 PM UTC

m000 wrote: post #238

Isn't the title kind of self-conflicting? Dependency cooldowns work because not everybody is using them. The more people start using dependency cooldowns, the less effective they become.

There are comments elsewhere in the discussion indicating that these attacks tend to be discovered by automated scanners and the maintainers themselves, not by customers negatively impacted.