[darth_avocado]

There is something to be said about the need to keep all the packages as the latest and the greatest at all times. Every minor version update doesn’t need to be immediately applied. And maybe high and critical vulnerabilities don’t need to be a minor version upgrade.

[Waterluvian]

I’m having a real problem at work with security theatre and the growing push to obsess over numbers of “vulnerabilities” in our projects. And then auto Dependabot PRs that encourage churn to fix issues that if an informed person actually reviews easily concludes it doesn’t affect us in the slightest.

[chrisweekly]

"maybe high and critical vulnerabilities don’t need to be a minor version upgrade"

huh? what do you suggest instead?

[darth_avocado]

A separate pathway to updates. At the moment there is a pressure to keep all the packages updated at all times. Every time a new version of a random package deep in the dependency tree gets published, you roll a dice: is it a bunch of bug fixes that I don’t care about or a vulnerability patch that need to apply immediately? Since it could be either most devs just auto pilot on updates. This creates an environment where newly introduced vulnerabilities get promoted rather quickly before the version matures. Sure, waiting a few days to update a package sounds great, but there is no guarantee that the vulnerability will be found quickly.

To give you a context, I get 20-30 PRs a week across all my repos with potentially hundreds of packages (non distinct) from dependabot. I give it a cursory look and try to get a summary of changes. Do I evaluate every single package update? Nope.

[chrisweekly]

Huh? Sorry but both of your comments are frankly incoherent. I have deep experience maintaining large dependency graphs and empatjize with the frustration about CVEs in deep transitive deps, but I can't make head or tail of your "separate pathway".