First-Party Code

When run, cargo vet invokes the cargo metadata subcommand to learn about the crate graph. When traversing the graph, cargo vet enforces audits for all dependencies.

Generally speaking, all other nodes in the graph are considered trusted and therefore non-auditable. This includes root crates, path dependencies, git dependencies, and custom ( registry dependencies.

However, there are some situations which blur the line between first- and third-party code. This can occur, for example, when the [patch] table is used to replace the contents of a package with a locally-modified version. Sometimes the replacement is rewritten from scratch, but often it's derived from the original, sometimes just with a single modification. Insofar as the package you're using is still primarily third-party code, you'll want to audit it like anything else — but cargo-vet has no foolproof way to mechanically deduce whether the replacement is a derived work.

To ensure the right thing happens, cargo-vet detects these ambiguous situations and requires the user to specify the intended behavior. Specifically, if there exists a public crate with the same name and version as a given first-party crate, cargo-vet will require a policy entry for that crate specifying audit-as-crates-io as either true or false1. If it's set to true, cargo-vet will perform audit enforcement.

When enabled for a git dependency, this enforcement is precise. It requires an audit for the base published version that exists on, and then one or more delta audits from that base version to the specific git commit used by the build graph. Git commits are identified with an extended x.y.z@git:SHA syntax. They may only appear in delta audits and should be performed relative to the nearest published version, which ensures that audit information is recorded in terms of published versions wherever possible for the sake of reusability by others.

When enabled for a path dependency, this enforcement is not precise, because cargo-vet lacks a hash by which to uniquely identify the actual package contents. In this case, only an audit for the base published version is required. It's important to note that any audits for such crates always correspond to the original version. This is what inspect and certify will display, and this is what you should review before certifying, since others in the ecosystem may rely on your audits when using the original crate without your particular modifications.

If audit-as-crates-io is enabled for a path dependency with a version which has not been published on, cargo-vet will instead require an audit of the latest published version before the local version, ensuring all audits correspond to a crate on crates.io2. If the local version is later published, cargo vet will warn you, allowing you to update your audits.



To enable an easy setup experience, cargo vet init will attempt to guess the value of audit-as-crates-io for pre-existing packages during initialization, and generate exemptions for the packages for which the generated value is true. At present it will guess true if either the description or repository fields in Cargo.toml are non-empty and match the current values on This behavior can also be triggered for newly-added dependencies with cargo vet regenerate audit-as-crates-io, but you should verify the results.


Which version is used for an unpublished crate will be recorded in imports.lock to ensure that cargo vet will continue to pass as new versions are published. Stale unpublished entries will be cleaned up by prune when they are no longer required for cargo vet to pass, and can also be regenerated using cargo vet regenerate unpublished, though this may cause cargo vet to start failing.