NPM has, specifically and deliberately, played down the successful theft here, making out that they completely foiled it.

If they hadn't done such a scummy, corporate spin job on this, I'd be inclined to agree with you - but they did.

npm encourages an auto-upgrading versioning scheme: take version x or higher.

It's great for keeping dependencies up-to-date, but this makes it immensely vulnerable to the kind of malware injection, as publishing a library version with payload will immediately propagate throughout the ecosystem.

In most other version managers (e.g. maven) every library and application specifies a hard-coded version, which requires users to manually upgrade, giving a window were a malicious version can be detected before it affects anyone.

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.

NPM isn't being singled out as part of a hypothetical risk analysis, this is about an attack that actually happened via NPM.

Semver probably makes the problem worse though.

how?

Dependency ranges mean package updates happen automatically. So a minor release could contain malicious code without anyone noticing. I still think semver is worthwhile even if it a little bit more vulnerable to this kind of attack.

Yeah, but a dependency attack is a rarer issue than out-of-date dependencies that contain known security vulnerabilities.

Because if you don't consider SemVer as part of your threat model, you'll specify "v1.2.3 or above" instead of "v1.2.3".