Rust supply-chain security: cargo-audit, cargo-deny and cargo-vet

Rust stops memory bugs in your code, but it cannot stop a malicious crate you add to Cargo.toml yourself. In September 2025 the crates.io team removed two crates, faster_log and async_println. Both posed as logging libraries; when a project using them was run or tested, the payload scanned log files for Ethereum and Solana keys and sent them out. They had about 8,400 downloads before discovery. Memory safety is one thing; supply-chain safety is another, and it needs its own tools.

Why Rust dependencies are an attack surface

• Deep dependency trees: a project with a few direct dependencies often pulls in hundreds of indirect crates.
• Code that runs at build time: build.rs and procedural macros execute on developer machines and CI during compilation, before you ever run the program.
• Typosquatting: crate names that look like popular ones, waiting for a typo.
• Real flaws in legitimate crates: even good code gets CVEs, especially inside unsafe blocks.

The toolkit: one tool per job

RustSec: the shared data source

cargo-audit and cargo-deny read the RustSec Advisory Database, maintained by the Rust Secure Code Working Group. Its data is exported in real time to OSV and reused by the GitHub Advisory Database and Debian. Each finding names the crate, version, advisory ID, the fix (usually an upgrade) and the path through your dependency tree, so you know where the vulnerable crate comes from.

cargo-vet: from "no CVE" to "someone read it"

cargo-audit only catches vulnerabilities that have already been reported. A brand-new malicious crate slips through. cargo-vet, built by Mozilla, targets exactly that gap: every dependency must carry an audit from your team or an organisation you trust. To keep the workload manageable it supports:

• Shared audits: import audit results from other organisations using the same crates.
• Relative audits: review only the diff between two versions; if the old one was vetted, the new one is too.
• Deferred audits: put unvetted dependencies on an exemptions list and ratchet it down over time, so existing projects can adopt it today.

Risks and caveats

• No single tool is enough: audit catches known flaws, vet catches unread code, and neither replaces keeping your dependency count down.
• Ignored warnings: if CI only prints warnings without failing the build, nobody reads them after a few weeks.
• Auditing takes effort: cargo-vet needs humans who actually read code; start with the exemptions list and audit new dependencies first.
• Lock files: if you don't commit Cargo.lock for applications, each build may pull different versions, including one that was just poisoned.

How to apply it

• Dev: Before adding a crate, check the exact name, download count, maintainers and source repo. Run cargo audit locally before opening a PR.
• Tech Lead: Put cargo deny check in CI as a build-breaking step, and add a scheduled cargo audit job (a ready-made GitHub Action exists) to catch new advisories even when no code changes. For sensitive products, turn on cargo-vet for new dependencies.
• PM: Moving to Rust reduces memory bugs, not supply-chain risk. Budget for dependency audits the same way you budget for code review.