A look at cargo-vet in 2026

At Light Squares we love cargo-vet. It’s baked into our software engineering practices as an important step to harden our software supply chain. Unlike a CVE scanner, cargo-vet requires auditing (vetting) of the code changes in third-party dependencies when they are introduced or updated. It can therefore stop malicious code before it becomes part of the product, rather than reacting to discovered CVEs later.

What is cargo-vet

Cargo-vet is a CLI built by people at Mozilla. It integrates with Rust’s build system, cargo, and enforces the invariant that every active dependency has been audited or explicitly exempted. Audits can be full, e.g. all code in version 1.2; or incremental (cargo-vet calls these delta audits). For instance, if there is already an audit for version 1.0, we only have to look at the code changes between 1.0 and 1.2. Incremental audits are a key ingredient for making the system scale.

Another ingredient for scale is the ability to import other people’s audits. These are published as .toml files by other tool users, e.g. Mozilla and Google. As we discuss below, these audit feeds might lag behind the latest versions on crates.io. Exemptions let a project keep moving in the meantime, until an upstream audit arrives or it writes its own.

By default, cargo-vet comes with two audit criteria: safe to run and safe to deploy. The safe to run criterion rules out the most egregious malicious code: credential exfiltration, reverse shells, and developer machine compromise. A CI pipeline should always enforce that cargo-vet passes for safe to run before any real build steps are executed, to safeguard important production tokens. A crate is safe to deploy if it does not introduce security vulnerabilities when exposed to untrusted input. In particular, unsafe code should be sound and interactions with the environment, e.g. environment variables, hardened. Safe to deploy implies safe to run. The full list of criteria is defined in the GitHub repository and acknowledged by the reviewer when they record an audit. Note that neither of these criteria requires a full security or cryptographic audit. They are meant to significantly level up the baseline checks and prevent incidents like the xz-utils backdoor and the CrateDepression typosquatting campaign on crates.io.

Requiring a full audit of all dependencies all at once would present a big hurdle for existing projects trying to adopt cargo-vet. Therefore, cargo-vet allows users to add exemptions for individual crates and to mark publishers as trusted. It also provides tools to later replace exemptions as (incremental) audits become available.

Our methodology

We scraped GitHub for repositories that contain a supply-chain/ directory with config.toml, audits.toml, or imports.lock, using full-code search to create a list of active projects using cargo-vet. Code search excludes very large repositories, and therefore we manually added mozilla-firefox/firefox and chromium/chromium to our seed list. Next we downloaded local copies of every project’s cargo-vet .toml files, and cloned the 150 most-starred projects for their full Cargo.lock history. In total we found 408 repositories, which include well-known projects such as Firefox, Chromium, Tauri, and Wasmtime. The adoption over time shows a clear trend:

Additionally, we downloaded the index of crates.io, totaling 306k crates with 2.7m published versions, as well as the source code of the crate versions that appear in the dependency updates we observed. This resulted in a total of 30k versions from 5.7k crates. We keep the full sources to later calculate the size of the diffs, that is, the number of added and removed lines as they are shown when performing incremental audits. See below the monthly review burden coming from these crates:

Similarly, we imported the 9 big audit feeds with a total of 7k individual audits. In our dataset, 326 of 408 projects import at least one audit feed. See below the number of audits published:

Challenge 1: Audit workload is high

Across the version pairs we analyzed, the ecosystem shipped 56m changed lines of Rust code between 2020 and mid-2026. That is quite a bit. Weighted by how often the projects in our dataset actually pulled those updates, it adds up to 182m lines across 82k update events. A single update is small (104 changed lines at the median) but they never stop coming.

For a project that wants to stay fully vetted, the median weekly audit workload is 8.7k changed lines; at the 90th percentile it exceeds 50k lines. In larger teams the burden is distributed across many shoulders, but it easily adds multiple FTE days of maintenance work.

That is on the one hand expensive, and on the other hand it can lead to “rubber stamping” audits, where the team approves updates without a thorough review. Not with bad intent, but simply because it’s the best available prioritisation. This explains why so many dependencies remain unaudited.

Challenge 2: Many important crates remain unaudited, leading to exemptions

The good news first: of the top 100 downloaded crates, all are audited by at least one registry. This number drops to 90% for the top 500 crates (71% for the top 1000). The first crate without any registry audit is the popular HTTP client library reqwest, at download rank 138.

As a result, virtually all projects have a long list of exemptions. The median project carries 131 exemptions; the mean is 206, pulled up by a few very large dependency trees. The most frequently exempted crates are once_cell, getrandom, and typenum, each with more than 750m downloads.

A notable outlier: the SecureDrop whistleblowing tool is the only large cargo-vet adopter with no exemptions in its supply-chain/config.toml file. Instead, it combines 47 audits of its own with 6 imported feeds.

Challenge 3: Audits lag behind

Decentralized audit feeds are cargo-vet’s answer to distributing load. However, today there are only 9 big registries whose 7k audits cover 1.9k crates.

Audits take time, so they are never instant. Large project feeds also typically add new audits only once they adopt the new version themselves. Across the registries, the median lag between a crates.io release and its audit is 29 days, and only 51% of audits land within 30 days.

Importantly, a missing audit combined with rigid CI gates might delay updates, although exemptions provide an escape hatch. For published RustSec advisories, an audit of the fixed version existed in only 29% of cases by the time the project shipped the fix. Another 31% were audited later, while 40% of the adopted fix versions never received an audit at all.

Conclusion

Cargo-vet is a step towards proactive supply chain security. However, as software development accelerates, its maintenance burden limits the size and velocity of projects that can use it. Exemptions are a great way to bootstrap adoption, but they increasingly become permanent. We believe that AI-assisted initial audits provide a pragmatic trade-off that can fill the gap: covering a wide range of crates while reducing the audit lag.