I avoid anything to do with NPM, except for the typescript compiler, and I'm looking forward to the rewrite in Go where I can remove even that. For this reason.
As a comparison, in Go, you have minimum version spec, and it takes great pains to never execute anything you download, even during compilation stage.
NPM will often have different source then the github repo source. How does anyone even trust the system?
The obscurity of languages other than JavaScript will only work as a security measure for so long.
None of it will help you when you're executing the binaries you built, regardless of which language they were written in.
Lavamoat would, if you get to the point of running your program with lavamoat-node or built with the lavamoat webpack plugin: https://lavamoat.github.io/guides/getting-started/
Sure it would... isn't that the whole point of Deno? The binary can't exfiltrate anything if you don't let it connect to the net.
I have seen so many takes lamenting how this kind of supply chain attack is such a difficult problem to fix.
No it really isn't. It's an ecosystem and cultural problem that npm encourages huge dependency trees that make it impractical to review dependency updates so developers just don't.
The difficulty comes in trying to change the entire culture.
“Stop doing that!”
“But I wanna!”
Other languages has similar package managers as npm, but with much less issues, so it can be fixed without changing the package manager completely.
It is an ecosystem and culture that learned nothing from the debacle of left pad. And it is an affliction that many organizations face and it is only going to get worse with the advent of AI assisted coding (and it does not have to be).
There simply arent enough adults in the room with the ability to tell the children (or VC's and business people) NO. And getting an "AI" to say no is next to impossible unless you're probing it on a "social issue".
And before you know it, you have a multitude of distributions to choose from, each with their own issues...
Source available beats open source from a security perspective.
The alternative is C++, where every project essentially starts by reinventing the wheel, which comes with its own set of vulnerabilities.
I'm saying this without a clear idea of how to fix this very real problem.
Sure, in 1995.
Most C++ projects nowadays belong to some fairly well understood domain and for every broad domain there is usually one or two large 'ecosystem' libraries that come batteries included. Huge monolithic dependency with well stablished governance instead of 1000 small ones.
Examples of such ecosystems are Qt, LLVM, ROOT, tensorflow, etc. For smaller projects that want something slightly more than a standard library but not belonging to a clear ecosystem like the above you have boost, folly, abseil, etc.
Most of these started by someone deciding to reinvent the wheel decades ago, but there's no real reason to do that in 2025.
Whenever you download an open-source program and you don't have to compile it first, you're at risk of running code that is not necessarily what's in the publicly-available source code.
This can even apply to source code itself when distributed through two different channels, as we saw in the xz backdoor attempt. (The release tarball contained different code to the repository.)