4 ms·

From what I can tell, there appears to be two camps. 1) Do not update dependencies (because updating to the latest version just because is silly) 2) Update dep

From what I can tell, there appears to be two camps. 1) Do not update dependencies (because updating to the latest version just because is silly) 2) Update dependencies (because security) Personally, I fall into the second group (with caveats). I've found that Dependabot helps with the tedious work of updating versions by hand but at the same time provides a check so that I manually approve. This seems to work out to be a decent balance. I've also moved away from using :latest or @v2 etc. and switched to using commit hashes/image digests. Once again, Dependabot is helpful for tracking changes/updates once you switch over. The one annoying thing is that Dependabot does not always trigger on a regular basis (once a day) but I've found that bumping .github/dependabot.yml reliably triggers it.

yjftsjthsd-h 4y ago
> 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.
- newman314 4y ago
  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.)
  - yjftsjthsd-h 4y ago
    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.
mbesto 4y ago
> 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?
- zie 4y ago
  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.
  - mbesto 4y ago
    Fair. But do most companies know whether the 638 child dependencies on <insert JS library here> affect them or not?
    - zie 4y ago
      LOL! only 638? That might be low :)
- pojzon 4y ago
  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.
  - jimt1234 4y ago
    "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.
    - pojzon 4y ago
      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.
notreallyserio 4y ago
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.
kkfx 4y ago
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.
prepend 4y ago
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.
layer8 4y ago
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.
jhutchings0 4y ago
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.

yjftsjthsd-h 4y ago

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

newman314 4y ago
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.)
- yjftsjthsd-h 4y ago
  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.

mbesto 4y ago

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

zie 4y ago
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.
- mbesto 4y ago
  Fair. But do most companies know whether the 638 child dependencies on <insert JS library here> affect them or not?
  - zie 4y ago
    LOL! only 638? That might be low :)
pojzon 4y ago
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.
- jimt1234 4y ago
  "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.
  - pojzon 4y ago
    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.

notreallyserio 4y ago

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.

kkfx 4y ago

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.

prepend 4y ago

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.

layer8 4y ago

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.

jhutchings0 4y ago

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.