[AndreasHae]

Nowadays there are automated tools like Dependabot (0) or RenovateBot (1) that make it simple to keep dependencies up to date. I can imagine the need originated from the JS ecosystem, but from a security standpoint it makes sense for almost any stack.

0: https://github.com/dependabot

1: https://docs.renovatebot.com/

[alkonaut]

Creating PRs with suggested outputs is one thing. But automating it all the way to deployment seems a bit much

[AndreasHae]

I think the idea is that for minor updates or patches, any potential breakages should be caught by the build pipeline or rolling deployments with automated rollback strategies (if you’re at a scale where this is feasible). Major updates will probably fail in the pipeline and require manual intervention either way.

I don’t think it makes sense for every project, but if recovery options are cheap then I don’t see anything that speaks against it.

[trueismywork]

Even in presence of an xz like attack?

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