Light Squares
← Back to blog

cargo audit vs cargo vet

After we published our blog post about the arrayref supply chain compromise, we had the chance to speak at the London Rust Meetup. After the talk, many asked: “We already run cargo audit in CI. Isn’t that enough?”

A wooden balance scale on a desk

It is a fair question. Many teams run cargo audit – arguably more than who run cargo vet. Both tools also seem to address the same issue of keeping dependencies secure. However, in practice they address different questions when it comes to software supply security.

What cargo audit does

cargo audit asks: “Is a problem already known for this package version?” Technically, cargo audit reads your Cargo.lock file and matches every crate including its version against the RustSec Advisory Database, a community-maintained database of security advisories of the Rust ecosystem. It just needs seconds, no configuration, and costs you and your team nothing to adopt. So there is no reason to not leverage the advantages of cargo audit in every Rust project. However, it means it can only warn you about issues that have already been reported.

What cargo vet does

cargo vet asks a different question: “Has a trusted human actually looked at this code or update?” It keeps a record of audits, your own and ones imported from organisations like Mozilla or Google, and refuses any dependency version that is neither audited against your criteria nor explicitly exempted. Whether an advisory exists is irrelevant to cargo vet. What matters is whether the code has been reviewed. Therefore, it can catch issues before they have been reported.

What’s the price?

The price of the tools is very different. cargo audit outsources the work to the RustSec community and is therefore nearly free. cargo vet insists that the review is done and someone has to do it. A lot of popular dependencies are covered by audits by others, e.g. Google, that you can import into your project. However, even then our analysis of the cargo-vet ecosystem found that a fully vetted project faces a median review burden of 8,700 changed lines of code in a dependency update per week!

Side by side

cargo auditcargo vet
QuestionIs a problem already known for this version?Has a trusted party reviewed this code?
Data sourceRustSec Advisory DatabaseAudit records, yours and imported
CatchesPublished advisoriesAny unreviewed code, including zero-day supply chain attacks
When it firesAfter discovery and disclosureBefore first use, if the audit actually happens
Cost to adoptMinutesMedian 8,700 lines of dependency diff per week (fully-vetted)
Failure modeThe exposure window before an advisory existscargo vet regenerate exemptions (deadline pressure)
ExamplesReDoS in regexarrayref: a malicious change nobody had read

Let’s have a look at arrayref

Quick recap for anyone who missed it: on 20 August 2026 an attacker used a maintainer’s crates.io account to publish an updated version of arrayref, whose only change was a new dependency on proc-macro1, a typosquat of proc-macro2 carrying a build.rs file that downloaded and ran a remote binary during compilation. The malicious version was removed about 86 minutes later. The full story is in one of our earlier posts.

For those 86 minutes, cargo audit reported a clean lockfile, because the window is by definition the time before an advisory exists.

Cargo vet would have flagged the update immediately as an unaudited delta from 0.3.9 to 0.3.10, plus proc-macro1 arriving as a never-seen-before crate with no audit history. No advisory was required at this point.

86 minutes is an unusually narrow window. In case of the supply chain attack on xz-utils, malicious commits were part of the repository for weeks, after years of social engineering to get there (one of our co-founders wrote a detailed research paper about this supply chain attack). That highlights one potential learning from such attacks where the window of opportunity depends on the attacker’s luck and the community’s attention, not on the tooling.

Reactive and proactive

Cargo audit is a reactive security control as it fires after discovery and disclosure. Cargo vet is a proactive tool as it blocks unreviewed code before it runs. So the answer to the question from the meetup is no, cargo audit alone is not enough. Run both.

However, it’s worth mentioning that both tools have their limits. cargo audit is bounded by disclosure and cargo vet is bounded by audit (in time). The first limit is especially critical. For a human, 86 minutes is not much time, but an always-on agent can exploit such a window easily.

Reactive controls cannot win that race.

That second bound is the one we are currently working on. Dependency Canary publishes attested AI audits of dependency updates within 24 hours of release, in cargo-vet compatible format. It does not replace either tool, but it supports the community in reading the diff in time.

Light Squares builds security products that replace trust with proof. Dependency Canary is in development and we are looking for design partners. Get in touch.

Credits: cover photo by Sora Shimazaki on Pexels.