Q.cargo audit vs cargo deny: which one should gate your CI?

TL;DR: The choice matters less than running either one. tokio-tar has had an unfixed advisory (RUSTSEC-2025-0111) for a year, and crates.io still served it 46,618 times a day in October 2026, up from 29,543 in August. Of the 28 crates whose latest release requires it, 9 shipped in 2026. Every one of those builds would have failed a single cargo deny check advisories or cargo audit step.

Rust's reputation for safety ends at the borrow checker. A logic bug in an abandoned tar parser compiles fine, passes tests and ships. The only thing between a public advisory and your release binary is a CI step someone chose to add. Here is what each option actually checks.

Key facts

What each tool checks, from each project's README and docs. Table by Tensorust, Oct 28 2026.

cargo audit: the smoke alarm

cargo audit reads your Cargo.lock, fetches the RustSec database and prints every match with its RUSTSEC ID, the affected crate and version, and the fixed versions if any exist. Exit code 1 on a vulnerability, so CI fails. Unmaintained and yanked crates show as warnings unless you pass --deny warnings.

Strengths: zero config, one line in CI, and it reads lockfiles of projects you do not own. It also has cargo audit bin, which scans a compiled binary built with cargo auditable, so you can check what is actually deployed, not just what is in the repo. Full walkthrough: our cargo audit guide.

cargo deny: the policy file

cargo deny init writes a deny.toml with four sections, and cargo deny check runs all of them:

• advisories: the RustSec check, with an ignore list for IDs you have reviewed.
• licenses: an allow-list (MIT, Apache-2.0 and so on). A crate under a license you did not allow fails the build. This is the check legal teams ask for.
• bans: forbid specific crates (say, openssl when you standardized on rustls) and flag duplicate versions of the same crate, which bloat compile times.
• sources: only allow crates.io, or your private registry, and named git repos. A dependency quietly pointing at a random fork fails.

Run just the security part with cargo deny check advisories. The policy lives in the repo, reviewed like code.

Which one to run

• Solo crate or small app, you want a vulnerability gate today: cargo audit. One step, done.
• Company codebase, anything shipped to customers, or more than a few contributors: cargo deny. License and source rules catch problems an advisory database never will.
• Both is fine. They do not conflict. Some teams run cargo deny check on every pull request and cargo audit on a nightly schedule, because new advisories get published against code that did not change.

That last point is the one people miss. A green build last month says nothing about today. tokio-tar did not change between July 2023 and October 2025; the advisory did. Only a scheduled run catches that.

Builds still fetching a crate with no fix. crates.io, pulled Oct 28 2026.

Common misconceptions

What to do now

Add one of these to CI today:

cargo audit                    # vulnerability gate, no config
cargo deny init && cargo deny check   # full policy

Schedule it nightly as well as on pull requests. Then check whether you are already carrying tokio-tar with the 28-dependent list, see the same pattern in the zip crate breakdown, or paste a lockfile into the Cargo.lock checker. If a flagged crate breaks your build when you swap it, our paid Rust fix handles it within 24 hours or a full refund.

FAQ

What is the difference between cargo audit and cargo deny?

cargo audit (from the RustSec project) checks Cargo.lock against the RustSec advisory database for vulnerable, unmaintained and yanked crates. cargo deny (from Embark Studios) runs the same advisory check plus license, banned-crate and source checks, configured in deny.toml.

Do cargo audit and cargo deny use the same database?

Yes. Both read the RustSec advisory-db on GitHub, so a RUSTSEC ID flagged by one is flagged by the other.

Should I use cargo audit or cargo deny in CI?

If you only need a vulnerability gate, cargo audit is one command with no config. If you also care about licenses, duplicate or banned crates, or where crates come from, use cargo deny and run cargo deny check in CI.

Can cargo deny replace cargo audit?

For CI gating, yes: cargo deny check advisories covers the same advisories. cargo audit still has extras, like scanning a compiled binary built with cargo auditable (cargo audit bin).

How do I ignore an advisory in cargo deny?

Add the RUSTSEC ID to the ignore list under [advisories] in deny.toml, ideally with a reason. In cargo audit, use audit.toml or the --ignore flag.

Sources

All checked October 28, 2026.

• RustSec, rustsec/rustsec (cargo-audit) and advisory-db.
• Embark Studios, cargo-deny and the cargo-deny book.
• RustSec, audit-check GitHub Action.
• Embark Studios, cargo-deny-action.
• RustSec, RUSTSEC-2025-0111, tokio-tar.
• crates.io, tokio-tar downloads, pulled Oct 28 2026.
• Images: card, table and chart by Tensorust.