A Crate Audit Is a Trust Decision With a Paper Trail

A Rust project can gain third-party code through a new dependency or an update. Cargo Vet gives a team a way to record why it accepts that code. It checks the dependency graph against audits, imported audits, trusted publishers, and explicit exemptions. Its overview describes a workflow in which a new crate or version can fail the check until someone supplies acceptable evidence or changes the project’s policy.

An audit states a specific claim

An audit is tied to a crate, a version or version change, and a criterion. Cargo Vet provides two built-in criteria. safe-to-run concerns whether code can be compiled, run, and tested in a controlled setting without surprising effects, such as accessing unrelated files or connecting to untrusted network endpoints. safe-to-deploy concerns serious security vulnerabilities in production software exposed to untrusted input. It implies safe-to-run. Teams can also define criteria with their own written descriptions.

The label matters because it tells a reviewer what was checked. A safe-to-run audit does not establish that a crate meets the production criterion. Even safe-to-deploy has a stated scope: its definition does not require a full logic review of the crate. Readers of an audit should inspect the criterion before treating the entry as assurance of a broader property.

The record follows the code

A project’s own audits live in audits.toml. A full audit names a version. A delta audit covers the change between two versions and records that the change preserves the selected criterion. The audit record format also allows a violation entry when a crate fails a criterion. These entries give future maintainers the version or version change and standard behind the decision.

When a dependency changes, Cargo Vet can suggest an inspection of the new version or a diff from an audited version. The audit workflow provides inspect, diff, and certify commands for viewing crate contents and recording the result. The diff helps focus human attention. A person still has to judge whether the changed code meets the criterion.

An import names whose judgment counts

A project can use another organization’s audit set through an imports entry in config.toml. Cargo Vet fetches that audit file and records the imported data in imports.lock. Its import documentation says the relationship is direct: the mechanism is not transitive: you cannot directly import someone else’s list of imports. The registry helps a team discover available audit sets; the team still chooses which ones to add.

This is a trust decision. An imported audit can spare a duplicate review, while the project relies on another group’s criterion and audit record. Built-in criteria keep the same meaning across projects. Foreign custom criteria need an explicit mapping before they carry a local meaning. The configuration reference also permits excluding particular crates from an import. Before adding one, review who maintains the audit set, what its criteria mean, and which versions its entries cover.

An exemption records an unresolved gap

Cargo Vet’s setup makes a passing check possible before a team audits its existing dependencies. cargo vet init lists those dependencies as exemptions in config.toml. The setup guide says the initial check succeeds because those exceptions cover the current set, even though the audit set is empty. A pass at that point reflects the recorded policy. It does not mean every dependency received a human audit.

An exemption names an exact version and the criteria being excused. The configuration reference provides a notes field for rationale. A useful note says why the code is needed, what review is missing, and what would remove the exemption. The audit workflow recommends reducing exemptions and provides cargo vet suggest to identify audit work that can shrink the list.

The check enforces the recorded choices

The overview describes a continuous integration check that examines the updated build graph when third-party code changes. If the required evidence is absent, verification fails. Cargo Vet can then point to possible imports or audit work. A team may also add an exemption. Each route deserves a recorded reason that a reviewer can assess.

The continuous integration guide shows cargo vet --locked as the check. The import guide says --locked uses recorded import data without fetching it again. Commit the supply-chain files alongside Cargo.lock, as the setup guide directs, so a dependency change and its trust decision can be reviewed together.

What to do

1. Run cargo vet init in a Rust project and inspect the new exemptions before accepting the first passing result. Commit the supply-chain files with Cargo.lock. The setup guide shows the starting state.
2. Read the criterion definitions. Decide which standard the project needs for production and development dependencies, and document any custom criterion in audits.toml.
3. For a new crate or update, run cargo vet. If it fails, inspect the crate or diff, then record a full or delta audit only after checking the stated criterion. Follow the audit workflow.
4. If you use an external audit, review its source and criterion mapping before adding the import. If you use an exemption, add a clear rationale and revisit it with cargo vet suggest. The import and configuration guides describe both records.
5. Run cargo vet --locked in continuous integration so future dependency changes face the recorded policy. The continuous integration guide shows the command.