For a security critical app not locking down the dependencies to audited versions seems very dangerous indeed and I believe there is some blame to be had there

You’re still vulnerable if you lock down dependencies during the period the malicious code is wild though. You have to actually audit your locked dependencies to consider yourself safe.

Isn't that expecting the car to be invented before the wheel?

From what I've seen, quite a few of these have been targetted attacks - the assailants have targetted specific variables that existed in a specific codebase that they knew imports their module. Of course, if you've only just started writing that codebase, your dependencies have no way of knowing where you're storing private keys (short of somehow scanning the object space for variable names like "private_key")

But yes, in theory I would love for any *-sensitive code to go through a thorough audit after every dependency update before a version gets released in the wild. I'm guessing that next-to-nobody has the resources for that kind of an effort though.

In this case, though, someone explicitly changed the included version to the malicious one.

This same thing is done anywhere semver is used or any other version range system. This includes python, rust, go, and many more.

Go's official package management solution actually only fetches the minimum specified version of each dependency. So auto-upgrades never happen except when you explicitly update a dependency to a newer version.