[staticassertion]

A combination of things, I think.

1. Running those builds in VMs is a good idea.

2. Monitoring for weird behavior.

3. Restricting build scripts from touching anything outside of the build directory.

4. Pressuring organizations like npm to step up their security game.

It would be really nice if package repositories:

1. Produced a signed audit log

2. Supported signing keys for said audit log

3. Supported strong 2FA methods

4. Created tooling that didn't run build scripts with full system access

etc etc etc

I started working on a crates.io mirror and a `cargo sandbox [build|check|etc]` command that would allow crates to specify a permissions manifest for their build scripts, store the policy in a lockfile, and then warn you if a locked policy increased in scope. I'm too busy to finish it but it isn't very hard to do.

[jschrf]

Thanks. I was thinking of a CI step that checked the SHA-256 of yarn.lock against a "last known good" value committed by an authorized committer and enforced by a branch policy.

Signed audit logs seem like a good idea.

Now...how to get developers to avoid using NPM and Yarn altogether on sensitive projects...