Auditing Your Cargo Dependencies: cargo-audit vs cargo-vet, and What Actually Catches an Attack

The arrayref supply chain attack we covered separately got caught in about two hours, but not by anything running inside the average Rust project’s own CI pipeline. It got caught by a third party manually watching for exactly this pattern. If your build process depends entirely on someone else noticing before you do, you have a gap. Here’s what actually closes it, what doesn’t, and how to set it up without turning every dependency bump into a research project.

Two different jobs, one confusing name overlap

Rust’s dependency-auditing tooling covers two genuinely different problems, and it’s worth being precise about which one you’re solving before you install anything.

Known-vulnerability scanning answers “does anything in my dependency tree have a publicly disclosed CVE?” cargo-audit is the standard tool here. It checks your Cargo.lock against the RustSec Advisory Database, a community-maintained list of crates with reported security issues, and fails your build if it finds a match.

Trust and review verification answers a completely different question: “has anyone actually looked at the source of this dependency before my build trusts it?” cargo-vet and cargo-crev both live here. Neither one knows or cares whether a crate has a CVE. They care whether a human, either you or someone in a trust network you’ve chosen to rely on, has reviewed the actual code.

The distinction matters because a brand-new malicious release, like the poisoned arrayref 0.3.10, has no CVE on day one. cargo-audit is blind to it by design, not by bug, because there is nothing yet to look up. That’s the whole reason the second category of tool exists.

Setting up cargo-audit

Installation and a first run:

cargo install cargo-audit
cargo audit

A clean project reports nothing found; a vulnerable dependency prints the advisory ID, the affected version range, and the patched version:

Crate:     example-crate
Version:   1.2.0
Title:     Use-after-free in buffer handling
Date:      2026-06-11
ID:        RUSTSEC-2026-0042
Solution:  Upgrade to >= 1.2.1

The version worth running is the one wired into CI, not the one you remember to run before a release:

# .github/workflows/audit.yml
name: cargo-audit
on: [pull_request, push]
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: rustsec/audit-check@v2
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

This fails the pull request the moment a dependency change introduces a known-vulnerable crate, which is early enough to matter, unlike catching it in production three weeks later.

Setting up cargo-vet

cargo-vet requires more upfront investment because it needs actual trust decisions, not just a database lookup. Initialize it in a project:

cargo install cargo-vet
cargo vet init

This creates a supply-chain/ directory tracking which dependencies are “audited” (someone reviewed the source), “exempted” (explicitly allowed without review, tracked so the gap is visible), or unaccounted for. Running cargo vet after that fails the build for anything unaccounted:

cargo vet
# error: 3 dependencies are missing from audits.toml:
#   proc-macro-unrelated-crate 2.1.0
#   ...

The realistic path for most teams isn’t auditing everything from scratch. cargo-vet supports importing existing audit sets from organizations that already review large swaths of the crates.io ecosystem:

cargo vet import mozilla https://raw.githubusercontent.com/mozilla/supply-chain/main/audits.toml
cargo vet import google https://raw.githubusercontent.com/google/rust-crate-audits/main/audits.toml

That turns “review 400 transitive dependencies” into “review the ones Mozilla and Google haven’t already vouched for,” which is a tractable afternoon of work instead of a project that never gets scheduled.

What none of this catches

Be honest with yourself about the gap that’s left. Even a fully configured cargo-vet setup only enforces review before a new dependency or version is trusted; it does nothing to stop a build.rs script from doing damage once it’s running, because Cargo’s build-script sandboxing is still limited in what it isolates as of 2026. The arrayref payload ran inside build.rs, with the same filesystem and network access as any other process on that machine.

The mitigation that actually contains that risk lives at the infrastructure layer, not in Cargo: run builds inside containers or CI runners with restricted network egress, so a build script trying to phone home for a second-stage payload has nowhere to reach. That’s a change to your CI environment, not a cargo install away.

Layer	Tool	Catches
Known CVEs	cargo-audit	Already-disclosed vulnerabilities in your lock file
Unmaintained / duplicate crates	cargo-deny	License issues, yanked crates, dependency bloat
Trust before upgrade	cargo-vet / cargo-crev	Unreviewed new dependencies or version bumps
Build-time execution	Sandboxed CI runners	A malicious build.rs reaching the network

Where to actually start

Don’t try to retrofit all four layers onto an existing project in one sitting. Add cargo-audit to CI first, it’s a ten-minute setup with immediate, low-noise value. Add cargo-deny next for maintenance-status checks. Save cargo-vet for when you’re ready to import an existing trust set rather than auditing from zero, and treat build-script sandboxing as an infrastructure project with its own timeline, not a checkbox on this list.

The realistic goal isn’t “audit everything.” It’s closing the specific gap that let the arrayref attack work: nothing in a typical project’s CI pipeline would have questioned a routine-looking dependency bump, because nothing was set up to ask.