> 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.

For most things in life that hit us periodically, we try to buffer them into manageable amounts so that when we address them, we do them all at once, benefiting from “economy of scale”, instead of having to constantly work on addressing everything that comes our way immediately. With package updates, however, another consideration is security: the longer you wait to release a security update, the more users may be vulnerable to it.

There’s no right answer. Every case is different, trying to impose a single rule for everyone just simplifies things beyond what is reasonable.

My logical read of the situation is that I end up making fewer overall changes if I end up upgrading a dependency once, not thrice, to a specific version. And the changes are their own source of risk.

In reality, one massive update is too big to digest and it never happens. So you're stuck on out-of-date packages having lost the ability to update.

That's never a problem until it suddenly is. Company is put at significant risk (courts want to reason by analogy and "engineers skipped maintenance and endangered people" is an easy one) and nobody is to blame since nobody owned the task.

I think that’s the response the “it’s never a real problem until suddenly it is” observation was trying to head off.

There’s always someone who doesn’t want to take the advice of all the people who’ve been burned because “well it’s never happened to me.” I used to be that someone myself. Until the day it happened to me.

Delaying non-security updates has the benefit of not wasting a team’s time when something regresses and is fixed in a quick follow up patch. Having to report issues upstream is not free.

Sure, by all means wait a week. Don't wait six months.

I've seen a similar benefit enforcing a 1 year instead of 3 year TLS cert lifetime limit in the past. It forces more automation and stronger processes.

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".

The direct vs transitive split helps a lot here. Most of that noise is transitive deps your app never actually calls with attacker-controlled input.

I don't think transitive definitionally means we can ignore it. Any input that I give to my direct dependencies could theoretically end up inside of its dependencies and I can't know that it doesn't without auditing the source.

The actual split is on which environments the dependency exists in and who can control inputs in those environments. For most private companies who aren't running CI on an open source repo, the dev/prod split is the operative one that determines what you can safely ignore.

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.

> The reality is that each update is its own potential security issue

Even beyond security issues: each update is a new opportunity for breakage, not only from bugs in the third-party package, but also from unexpected dependencies on the third-party package's behavior.

And that’s exactly why semantic versioning provides only an illusion of stability. This is also why ecosystems that don’t pin their versions such as floating versions that are the default in JavaScript ecosystems are so much more vulnerable from a security and a regression standpoint.

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.

As a previous sysadmin that does stuff in tangently related things to security (not the security person that makes these rules) I agree. The rules they come out with to address issues in operating systems that haven't been deployed in 10 years blows my mind.

"Ya, Windows something ancient had an issue with WevDAV 2 decades ago, but that is not a reason to block the http DELETE verb at the WAF"

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 keep getting things like "denial of service when the SCSS or whatever parse is given malicious input”. Great, that's part of the build chain, all of its inputs are stuff we control. Why do we care.

All of my services are internal, yet I am continually getting red alerts that there is a novel denial-of-service that needs to be patched immediately.

It's essentially blowback from the number-one security problem being out of date software with known vulnerabilities. It's also easy to measure without deeper knowledge of the system, so it gets focused on to the detriment of strategies based on deeper analysis and reducing overall attack surface.

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.