Dependencies must not be seen as "a blackbox someone else have built and distribute" but as part of your project, only developed by someone else. If you are the leader of your project it's your duty to review code from all developers participating to the project you are leading.

That way means you give a bit of trust to anyone, in the end we all work for a purpose, rouge agents are rare in any community, but not more than a bit, so updating is a must, not doing it means having someone who work for nothing, but with checks.

If that's overburden it's because actual IT development model, separate stuff for anything instead of an operating-system-environment-framework with a unique language (like ALL from the past) and a single application formed by tons of individual functions/methods/modules (again like ALL from the past) and such issue can't be solved keeping up the actual paradigm.

> 1) Do not update dependencies

We regularly ding companies that don't update dependencies. No offense, but how do developers sleep at night having their application littered with known vulnerabilities?

On the other hand, how do developers sleep at night after updating their dependencies as it will now be littered with new unknown vulnerabilities.

The biggest correlated constant for bugs is that more lines of code = more bugs. As dependencies get updated they add more new features that I probably don't care about which adds more lines of code and therefore more bugs and security vulnerabilities.

I appreciate there is a balance between the two, but in my experience updating dependencies has broken things a lot more often than not updating things has broken things, and when that happens I find it a bit of a ridiculous idea that the maintainer has somehow made their product "more secure"(something that is usually a low dev priority) while at the same time introducing new bugs with the new features (something which is a higher dev priority) and they didn't even get that right.

> (something that is usually a low dev priority)

I guess you just proved my point. Thanks.

One argument, if the vulnerabilities don't affect you for whatever reason, it probably doesn't matter much. Lots of vulns these days have a fair load of caveats attached, and if they don't apply, one could argue upgrading is not required.

Note: I'm not taking a stance on if I agree or not with this argument.

Fair. But do most companies know whether the 638 child dependencies on <insert JS library here> affect them or not?

LOL! only 638? That might be low :)

If the application is not exposed to public internet - who cares ?

TBH most best practices preach for security by obscurity.

If you talk to any good vulnerabilities researcher - they will tell you what to really look out for.

"We're not internet-facing, so we're not at risk, so we're not concerned with security." Standard misconception. I once worked with a team running a large Hadoop cluster. Everything in a private network. Nothing internet-facing. No risk, right? Well, a Python library they were importing got compromised and was using all their nodes to mine Monero. Oops! The cluster had been running for weeks. The only reason anyone knew about it was the performance of the cluster was terrible; all the CPUs were maxed, yet no jobs were running.

This example is a borderline case. This means that not only they got hacked but also pip repo they were using.

Which means that their provider also did not run any dependency scans.

Tho if they fetched that from github open source repo -> yup thats just incompetence.

> Do not update dependencies (because updating to the latest version just because is silly)

That's quite the straw man; I seriously doubt that anybody is saying you shouldn't update because it's "silly". Blindly pulling updates is how you get compromised by supply chain attacks.

Not naming names but certainly I've encountered open source projects that reject updating until the last possible second (end of life, security vulnerability etc.)

That can be a function of effort, too; updates can be disruptive, and not everyone has the CI+testing infrastructure to handle it without significant manual work. There's a reason LTS distros are a thing.

Dependabot was created with the philosophy that staying up to date all the time is the best strategy. The main reason for that is because if you wait to update until there's a CVE, there's a chance that you'll be so far out of date that you'll have to sort out breaking changes in your dependencies when there's urgency.

It's not a perfect strategy, since there's non-zero risk that the latest version was hijacked by a malicious user, but the chances of a hijacked dependency are much lower than the chances of relying on something with a known vulnerability.

It’s also easy to stick with #1 and leave pinned to specific versions and only update for security reasons.

This used to be a pain so automatically updating was an easy way to stay up to date and reduce risk. But now with dependabot, I can pin to specific versions and leave it there forever, until dependabot detects the vulnerability and submits a PR.

If you only have a limited number of dependencies and whose maintainers have a good culture of documenting their changes, then there’s the middle ground of checking the release notes/changelogs and only updating for relevant security fixes, and for other updates at your own discretion.

I figure if a dependency is good enough for a new project it's good enough for an existing one as well. Either way, it needs to be vetted.