It’s probably worth mentioning that this doesn’t sound like the back door was successful at all. Every package typically has around ~100-200 downloads immediately due to scanners and proxies.
This security response of under a day really sounds like a good improvement, although I still wish npm had some support for signatures so trusted packages can be trusted indefinitely.
At some level there's always going to be some dependencies unless you literally bootstrap the universe from first principles. And people like to use that as a rationalization for why they shouldn't bother going a little bit lower level than they normally would.
I recently put together my own personal blog after years of putting it off and letting domains go unused. I've thought about using Hugo, Jekyll, even Wordpress. But I just hated the thought of everything extra that comes with them.
But I also didn't want to handwrite all of my HTML, manually move files around, etc. So instead I wrote my own thing in about 20 lines of bash. Super easy to comprehend and I can fit it to exactly what I'm doing. It feels nicer versus typical Node stuff I do where it feels like I'm stuffing clowns in a car.
All of that is roughly available on the npm website, but isn't really exposed in the CLI.
System package installs then do a GPG check against those known good keyparts from trusted vendors which you've allowed and stop you when you have an unsigned package (being a bit light on detail here, each distribution handles it their own way). So the NPM (or Artifactory, etc.) ecosystem could invent an installable package of their GPG keys, and require all packages sourced from their server to be signed with this key -- this is how the EPEL 3rd party community repo works for example. These are all based on trusted humans having access to the signing keys and process, so there are layers of vetted/known folks required (not just anyone can walk into Mordor here).
This does not work though for some Linux distributions such as Ubuntu due to their original design. Debian/Ubuntu systems for example are at somewhat of a disadvantage here; from the beginning the DEB system design has eschewed GPG signing individual packages and instead sign repositories (which tends to also get disable/ignored if even used), they're at least now recommending HTTPS around apt which is nice.
For example, a DNS record belonging to twillio.com, saying their npm public key is “xyz”.
Then, to the point others mentioned here, you include the logic to verify this in the package managers, ie compare the signed package with the trustee public key. Although the verification would also be something that could easily be done by a human as well.
Your points of failure here are a) trusting the DNS system, which is acceptable for most use cases, and b) trusting the package manager, which is a similar situation to a above.
There are a few types of dns records that are meant for this already, depending on the specific, but probably a txt record is fine and I think what most people do now, though I could be wrong about that.
If you specify an exact package version, you can trust that to be immutable. NPM doesn't allow replacing of existing versions, only addition of new versions.