Build Script Audit Template for Rust Dependencies

Imagine you're compiling a Rust project, and hidden in the build process, a backdoor is executing. The source code appears clean, and your lockfile lists legitimate packages. Yet, a typosquatted dependency, introduced through a modified manifest, has just harvested your cloud credentials.

This scenario became a reality when North Korean state-sponsored actors compromised three popular Rust crates, arrayref, internment, and append-only-vec, in August 2024. The Sapphire Sleet group didn't alter the library source code. Instead, they modified package manifests to include a malicious dependency named proc-macro1, which executed during the build phase. Arrayref alone was present in about 75% of cloud environments running Rust applications, with 245,777,808 downloads.

The payload executed before compilation finished. No deployment or runtime execution was needed. Just cargo build, and your system was compromised.

This template provides a structured audit process to inspect your Rust dependency chain for similar threats, both now and in future intake cycles.

Purpose of This Template

Use this template to audit Rust projects for supply chain risks introduced through build-time dependencies. It focuses on:

• Identifying typosquatted or unexpected transitive dependencies in Cargo.toml and Cargo.lock
• Reviewing build scripts (build.rs) for unauthorized network calls or filesystem access
• Validating that package manifests haven't been altered to pull in malicious crates
• Establishing a repeatable process for assessing vendor-supplied Rust codebases

Integrate this into your vendor intake workflow and continuous monitoring of active arrangements.

Prerequisites

Before starting the audit, ensure you have:

1. Access to the full source tree, including Cargo.toml, Cargo.lock, and any build.rs files.
2. A sandboxed build environment to compile without risking production secrets.
3. Network monitoring tools (e.g., Wireshark, tcpdump) to capture outbound connections during build.
4. Dependency tree tools: Install cargo tree and cargo audit.
5. A baseline of known-good package names: Maintain a list of approved crates and their official maintainers.

If assessing a third-party vendor's Rust application, request these artifacts during due diligence. If they can't provide Cargo.lock or resist sharing build scripts, escalate.

The Audit Template

Copy this checklist into your vendor assessment workflow or internal audit log:

# Rust Dependency Audit Checklist

**Project Name:**  
**Vendor (if applicable):**  
**Audit Date:**  
**Auditor:**  

---

## 1. Manifest Review

- [ ] Open `Cargo.toml` in the root and all workspace members
- [ ] List all dependencies and dev-dependencies
- [ ] Flag any crate names that are close variants of popular packages (e.g., `proc-macro1` vs. `proc-macro`)
- [ ] Verify each dependency exists on [crates.io](https://crates.io) and matches the expected maintainer
- [ ] Check for unusual version pinning (e.g., a specific patch version when semantic ranges are standard)

**Findings:**

---

## 2. Lockfile Analysis

- [ ] Run `cargo tree --locked` to generate the full dependency graph
- [ ] Export output to a file: `cargo tree --locked > dependency-tree.txt`
- [ ] Search for any crate name not explicitly listed in `Cargo.toml`
- [ ] Cross-reference transitive dependencies against your approved package list
- [ ] Identify any crate with fewer than 10,000 downloads or no recent commits (check [crates.io](https://crates.io))

**Findings:**

---

## 3. Build Script Inspection

- [ ] Search the project for all `build.rs` files: `find . -name build.rs`
- [ ] For each build script, review for:
  - [ ] Network calls (e.g., `reqwest`, `curl`, raw TCP sockets)
  - [ ] Filesystem writes outside `OUT_DIR` or `CARGO_TARGET_DIR`
  - [ ] Execution of external binaries (`std::process::Command`)
  - [ ] Environment variable reads that could leak secrets
- [ ] If a build script makes network requests, document the endpoint and verify it's under the vendor's control

**Findings:**

---

## 4. Sandboxed Build Test

- [ ] Clone the project into an isolated environment (VM or container with no production credentials)
- [ ] Enable network monitoring before running `cargo build`
- [ ] Compile the project: `cargo build --release`
- [ ] Capture all outbound network connections during build
- [ ] Review logs for unexpected DNS queries, HTTP requests, or TLS handshakes
- [ ] Check for any files written outside the target directory

**Findings:**

---

## 5. Vulnerability Scan

- [ ] Run `cargo audit` to check for known CVEs in dependencies
- [ ] Review RustSec advisory database for any flagged crates
- [ ] Document any crates with open security advisories
- [ ] If a crate is unmaintained, assess [substitutability](/glossary/substitutability)

**Findings:**

---

## 6. Provenance Verification

- [ ] For critical dependencies, verify the crates.io package hash matches the Git repository tag
- [ ] Check the maintainer's GitHub profile for signs of account compromise (e.g., sudden ownership transfers, unusual commit patterns)
- [ ] If the vendor supplies a private registry, audit the registry's access controls and signing process

**Findings:**

---

## 7. Risk Scoring and Recommendation

**Overall Risk Level:** [Low / Medium / High / Critical]

**Recommendation:** [Approve / Approve with Conditions / Reject / Request Remediation]

**Conditions or Remediation Required:**

**Next Review Date:**

---

**Auditor Signature:**  
**Date:**

Customizing the Template

Adapt this template to your organization's risk governance framework:

• For pre-contractual assessment: Add a section requiring the vendor to attest that no build script makes external network calls without documented justification.
• For high-criticality vendors: Require cryptographic signing of all crates and verification of signatures during your build.
• For regulated environments: Map findings to SR 23-4 or EBA Outsourcing Guidelines requirements, particularly around sub-outsourcing and right to audit.
• For continuous monitoring: Schedule this audit quarterly for active vendor arrangements. Use cargo audit in your CI pipeline and alert on any new advisory.

If assessing a vendor that supplies compiled binaries rather than source, request a software bill of materials (SBOM) and run this audit against their declared dependencies. If they can't produce an SBOM, that's a red flag.

Validation Steps

After completing the audit:

1. Cross-check your findings with the Rust Security Response Team's advisory feed and RustSec database.
2. Test your sandboxed build a second time with network access fully disabled. If the build fails, investigate why it requires internet access.
3. Review incident escalation procedures with your vendor. If you discover a compromised dependency, how quickly can they respond? The Rust Security Response Team revoked credentials and removed malicious crate versions within hours of the August 2024 incident. Your vendor should have a comparable timeline.
4. Rotate secrets on any system that compiled the audited project before you validated it. Treat the build environment as potentially compromised until you've confirmed clean dependencies.
5. Document substitutability for each critical dependency. If arrayref were permanently compromised, could you replace it? The Sapphire Sleet campaign affected a crate with 245 million downloads, concentration risk is real.

State-sponsored actors are targeting the build phase because it's invisible to runtime security controls. Your vendor's code might be clean, but their dependency chain is an attack surface. Audit it like you'd audit their own engineering.