How to check your Cargo.lock for vulnerabilities with cargo audit

Step 01: Install cargo audit

cargo install cargo-audit --locked

This compiles the tool from crates.io and adds cargo audit as a subcommand. We used version 0.22.1. On a slow or low-memory machine the build takes a few minutes; it is a one-time cost.

Step 02: Scan the lockfile

cargo audit

The first run clones the RustSec database into ~/.cargo/advisory-db. Ours loaded 1,378 advisories. To scan a lockfile somewhere else, point at it:

cargo audit -f path/to/Cargo.lock

Our nine lockfiles held 2,330 package entries between them. Each scan took a couple of seconds once the database was local.

Step 03: Read the report

Our run on the Tokio Prompt lockfile, Oct 26 2026. Trimmed between the second finding and the summary; the database path is shortened.

Every finding has the same shape: Crate, Version, Title, Date, ID, URL, a Solution line with the first fixed version, and the Dependency tree that explains how it got into your build. Read the tree first. It tells you whether you can fix it with a lockfile bump or need to change a direct dependency.

What our worst lockfile actually had:

Source: cargo audit 0.22.1 output, RustSec IDs RUSTSEC-2026-0049 through RUSTSEC-2026-0382 plus RUSTSEC-2024-0437, Oct 26 2026.

Two patterns jump out. The TLS stack carries most of it: 15 of the 24 findings sit in rustls, rustls-webpki and webpki-roots, and 6 of those were published in the last two weeks (Oct 14 to Oct 20). And dev-dependencies count: the crossbeam-epoch finding came in only through criterion, a benchmark crate. It never ships in the binary, but the scanner cannot know that, so you decide.

Step 04: Fix with cargo update

Most fixes are patch releases inside your existing semver range, so the lockfile is the only thing that changes:

cargo update -p rustls
cargo update -p rustls-webpki
cargo update -p quinn-proto
cargo audit

When the Solution line names a new major version (protobuf 2.x to 3.7.2, rmcp 0.16 to 1.4 above), cargo update cannot get there. Find the parent in the dependency tree and bump it in Cargo.toml, or replace it. That is real work, and it is why old lockfiles rot: the cheap fixes pile up behind one expensive one.

To check one crate before you touch anything, every advisory has a page on our Rust advisory database, for example all rustls advisories.

Step 05: Gate CI on it

cargo audit exits 1 when it finds a vulnerability and 0 when it does not. We confirmed both: the 24-finding lockfile returned 1, the O'BLOCK lockfile returned 0. So in any CI system:

cargo install cargo-audit --locked
cargo audit

The O'BLOCK lockfile still had 2 warnings (paste and ttf-parser are unmaintained). They pass by default. Add -D warnings and they fail the build too; it returned 1 on the same file. Pick on purpose: unmaintained crates are a slow risk, not an emergency.

To accept a finding you have reviewed:

cargo audit --ignore RUSTSEC-2026-0204

or put the ID under [advisories] ignore = [...] in .cargo/audit.toml with a comment saying why.

Step 06: Re-check on a schedule

Your lockfile does not change, but the database does. Of the 24 findings in our worst file, 13 were published after July 1, 2026. Run the scan nightly or weekly, not only on push, or let something do it for you: our Cargo.lock check page shows the database date it used, and the weekly re-check option emails only what changed.