Is there a theoretical framework that can prevent this from happening? Proof-carrying code?

Object-capability model / capability-based security.

Do not let code to have access to things it's not supposed to access.

It's actually that simple. If you implemented a function which formats a string, it should not have access to `readFile`, for example.

Retrofitting it into JS isn't possible, though, as language is way too dynamic - self-modifying code, reflection, etc, means there's no isolation between modules.

In a language which is less dynamic it might be as easy as making a white-list for imports.

You can protect yourself using existing tools, but it's not trivial and requires serious custom work. Effectively you want minimal permissions and loud failures.

This is something I'm trying to polish for my system now, but the idea is: yarn (and bundler and others) needs to talk only to the repositories. That means yarn install is only allowed outbound connections to localhost running a proxy for packages. It can only write in tmp, its caches, and the current project's node_packages. It cannot read home files beyond specified ones (like .yarnrc). The alias to yarn strips the cloud credentials. All tokens used for installation are read-only. Then you have to do the same for the projects themselves.

On Linux, selinux can do this. On Mac, you have to fight a long battle with sandbox-exec, but it's kinda maybe working. (If it gained "allow exec with specified profile", it would be so much better)

But you may have guessed from the description so far - it's all very environment dependent, time sink-y, and often annoying. It will explode on issues though - try to touch ~/.aws/credentials for example and yarn will get killed and reported - which is exactly what we want.

But internally? The whole environment would have to be redone from scratch. Right now package installation will run any code it wants. It will compile extensions with gyp which is another way of custom code running. The whole system relies on arbitrary code execution and hopes it's secure. (It will never be) Capabilities are a fun idea, but would have to be seriously improved and scoped to work here.

Something similar to Deno's permission system, but operating at a package level instead of a process level.

When declaring dependencies, you'd also declare the permissions of those dependencies. So a package like `tinycolor` would never need network or disk access.

Probably signatures could alleviate most of these issues, as each publish would require the author to actually sign the artifact, and setup properly with hardware keys, this sort of malware couldn't spread. The NPM CI tokens that don't require 2fa kind of makes it less useful though.

Clojars (run by volunteers AFAIK) been doing signatures since forever, not sure why it's so difficult for Microsoft to follow their own yearly proclamation of "security is our top concern".

Manual verification of releases and chain-of-trust systems help a lot. See for example https://lucumr.pocoo.org/2019/7/29/dependency-scaling/

There are, but they have huge performance or usability penalties.

Stuff like intents "this is a math library, it is not allowed to access the network or filesystem".

At a higher level, you have app sandboxing, like on phones or Apple/Windows store. Sandboxed desktop apps are quite hated by developers - my app should be allowed to do whatever the fuck it wants.