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