[mason55]

Sure, why not? Are you suggesting that having a human in the loop, robotically bumping the version numbers of your dependencies would have mitigated it?

Lots of humans upgraded lots of dependencies without noticing, I doubt whoever is doing it in your org is special enough to be the one who would have caught it. And if they are, they should be working in security research, not bumping dependency versions in package.json.

[trueismywork]

I didn't mean human to update your dependencies but rather a security decision, whether auotnated or human, approves that dependabot recommends.

[alkonaut]

I bump versions of maybe 2-4 dependencies per year, for a 200 man-year project. It's not exactly overwhelming. But then it's not a JS project either.

[mason55]

I'm not sure how updating dependencies a few times a year makes you safer from a well-hidden supply chain attack.

Also, not sure what JS has to do with the xz attack.

The argument I was responding to is that automating your dependency updates somehow makes you more vulnerable to a supply chain attack.

I could see an argument that waiting X days from a dependency release to when you pull it in gives you a little time for other people to find issues. But that's orthogonal to whether you update dependencies automatically or manually, or whether you do it once/year or every day.

[alkonaut]

What I meant was that for maybe 3-4 packages total in a year, automation doesn't matter much. It's not a big cost. Risk wise you can be pretty conservative if you are in a high-risk scenario.

But usually I find that bumping dependencies is a detective work because unlike JS where you can depend on multiple versions of the same package, for .NET you can't. So if you update package A, there is a risk that you also update a transitive dependency C, which package B depends on but on the previous version. So even for what looks like trivial updates it's often a chore. Which is why I'm happy to have just a handful of dependencies.