cargo-deny / cargo-audit Failures - Advisories & Licenses in CI

By Kaveh Alemi·Latchkey

cargo audit or cargo deny flagged something in your dependency graph - a security advisory (RUSTSEC), a banned or duplicate crate, or a license outside your allow-list - and failed the build as a supply-chain gate.

What this error means

A cargo audit or cargo deny check step exits non-zero, listing the offending crate plus the advisory ID, license, or ban rule. The code compiles fine; the gate is rejecting a dependency, not a build error.

cargo output

error[vulnerability]: Vulnerable to a denial of service via crafted input
    ┌─ /home/runner/work/app/Cargo.lock:142
    │
142 │ time 0.1.45 registry+https://github.com/rust-lang/crates.io-index
    │ ^^^^^^^^^^^ RUSTSEC-2020-0071
    = solution: Upgrade to >=0.2.23

error: advisories check failed

Diagnose it: toolchain, features, or a stale target dir?

Cargo failures that only appear in CI are usually a different toolchain channel, a different feature set resolved by the dependency graph, or a target directory restored from a cache built with different flags.

Terminal

rustc --version --verbose
cargo --version
cat rust-toolchain.toml 2>/dev/null

# which features actually got enabled across the graph?
cargo tree -e features | head -40

# rule out a poisoned cache before anything else
cargo clean && cargo build --locked

Common causes

A dependency has a published advisory

A crate in the graph matches a RUSTSEC advisory (vulnerability or unmaintained). cargo audit/cargo deny advisories fails until it’s upgraded or explicitly ignored.

A license, ban, or duplicate rule tripped

cargo-deny also enforces license allow-lists, banned crates, and duplicate-version rules from deny.toml. A dependency outside those policies fails the corresponding check.

How to fix it

Upgrade or replace the flagged crate

The advisory usually names a fixed version - bump to it, or swap to a maintained alternative.

Terminal

cargo update -p time --precise 0.3.36
# re-run the gate
cargo audit
cargo deny check advisories bans licenses

Annotate an accepted finding in deny.toml

When a fix isn’t yet available, record a reviewed exception so the gate stays meaningful rather than disabled.

deny.toml

# deny.toml
[advisories]
ignore = ["RUSTSEC-2020-0071"]   # tracked: no upstream fix yet

[licenses]
allow = ["MIT", "Apache-2.0", "BSD-3-Clause"]

How to prevent it

Run cargo audit/cargo deny in CI so advisories surface on every PR.
Keep a reviewed deny.toml for licenses, bans, and time-boxed advisory ignores.
Upgrade flagged crates promptly instead of accumulating ignores.

Frequently asked questions

What causes cargo-deny / cargo-audit failures?

There are 2 common causes: a dependency has a published advisory and a license, ban, or duplicate rule tripped. A crate in the graph matches a RUSTSEC advisory (vulnerability or unmaintained).

How do I fix cargo-deny / cargo-audit failures?

There are 2 fixes depending on which cause you have: upgrade or replace the flagged crate and annotate an accepted finding in deny.toml. Work through them in order, since the first is the most common.

What does cargo-deny / cargo-audit failures actually mean?

A cargo audit or cargo deny check step exits non-zero, listing the offending crate plus the advisory ID, license, or ban rule.

How do I stop cargo-deny / cargo-audit failures happening again?

Run cargo audit/cargo deny in CI so advisories surface on every PR. The prevention section lists 3 changes that keep it from recurring.