cargo-deny can audit build scripts, but unfortunately not prevent execution of malicious build scripts exactly for the reason you gave. It could still help if you only ever use cargo add and update in a sandbox.

See https://embarkstudios.github.io/cargo-deny/checks/bans/cfg.h...

You can disable rust-analyzer running build scripts.

So, don't add dependencies before you audit the code? That seems like a pretty reasonable ask to me.

Safe-ish recommendation: Only add well-known, trusted crates. Failing that, treat unknown crates as malware or containing malware dependencies until proven otherwise. Test untested tools/crates in a VM/dev container to be sure they work properly before trust them. Use Mark I eyeball and Mark III brain too. :)

Audit and limit crates (cargo-deny &| cargo-crev, && --offline) until tools exist to audit build.rs safety semi-automatically ($$ safeguard.sh maybe).

The root problem is two parts:

1. crates.io doesn't do mandatory curation. Lack of curation is fail. It's time-consuming and costly for reviewers without a doubt, but so is letting an ecosystem gain maximum entropy (go to shit) by Tragedy of the Commons depending entirely on the honor system. Name squatting, low-quality, unmaintained, typosquatting, and malware are the consequences of too much self-service / semi-self-service freedom.

2. Many, many cargo subcommands are over-eager to run build.rs because it assumes trusted crates:

In an untrusted/uncurated crates world and a build.rs exists or exists in a selected dependency, it shouldn't run at cargo-add time (unless it must). If it exists, on first run, it should be presented to the user in a viewer for manual review unless a magic CLI flag/env var is specified to accept it.

These 2 factors combined appear to create a Swiss cheese holes failure mode for running arbitrary crate `cargo add`. I have confidence a suitable add-in workflow &| standard command &| repository workflow will be adjusted to reduce the attack surface of the ecosystem.