Dependency Auditing

As a project’s dependency graph grows, so does its exposure to security vulnerabilities and licensing conflicts. Vulnerabilities in transitive dependencies are particularly dangerous because they are easy to miss — your project may not directly depend on the affected crate, yet still ship the buggy code. Licensing is a separate but related concern: Cargo makes it trivially easy to add dependencies, and each one brings its own license terms that may conflict with your project’s requirements.

The Rust ecosystem has strong tooling for automating these checks. The RustSec project maintains a database of security advisories against Rust crates, and several tools build on it. This chapter covers three of them, each operating at a different level of rigor.

cargo-audit

cargo-audit is part of the RustSec project. It checks your crate’s dependencies against the RustSec advisory database by scanning the Cargo lockfile, covering both direct and transitive dependencies.

cargo install cargo-audit
cargo audit

If any dependency has a known vulnerability, cargo-audit prints a detailed advisory with the affected versions and suggested remediation (usually upgrading to a patched version). It exits with a nonzero status, making it straightforward to use as a CI gate.

cargo-deny

cargo-deny goes further than cargo-audit by acting as a general-purpose linter for your dependency graph. It checks four categories, each configurable independently:

• Advisories — the same RustSec database check that cargo-audit provides.
• Licenses — enforces an allowlist or denylist of acceptable licenses across all dependencies.
• Bans — prevents specific crates from appearing in your dependency tree, or flags duplicate versions of the same crate.
• Sources — restricts which registries or Git repositories dependencies may come from.

Configuration lives in a deny.toml file. Running cargo deny init generates a starter configuration with comments explaining each section.

cargo install cargo-deny
cargo deny init
cargo deny check

Each violation can be configured as an error or a warning, so you can incrementally adopt stricter policies without blocking all CI immediately.

cargo-vet

cargo-vet takes a fundamentally different approach from the advisory-based tools. Rather than checking against a database of known vulnerabilities, it enforces that every dependency has been explicitly audited and certified to meet specific criteria (such as “safe-to-deploy” or “safe-to-run”). Unaudited dependencies cause a build failure until someone reviews them.

The key insight is that audits are shareable. Organizations can publish their audit records, and other teams can import them. Both Google and Mozilla publish their Rust crate audits, so you can bootstrap your audit set by importing theirs and only need to manually review crates they haven’t covered.

This is a higher-effort approach than cargo-audit or cargo-deny, but it provides stronger guarantees: rather than reacting to known vulnerabilities, it ensures that human eyes have reviewed every piece of third-party code before it enters your project.

Setting Up

To start using cargo-vet, initialize it in your project:

cargo install cargo-vet
cargo vet init

This creates a supply-chain/ directory containing an audits.toml (where your audit certifications live) and an imports.lock (for audits imported from other organizations). Running cargo vet immediately after init will likely fail, because your existing dependencies have not been audited yet. You have a few options to get to a clean state:

• Import audits from organizations like Mozilla or Google using cargo vet import. This covers many popular crates without you having to review them yourself.
• Certify dependencies you have reviewed with cargo vet certify, which records your audit in audits.toml.
• Exempt dependencies you trust but have not reviewed with cargo vet suggest, which adds them to an exemptions list. This lets you adopt cargo-vet incrementally rather than auditing everything upfront.

Once cargo vet passes locally, commit the supply-chain/ directory. From that point on, cargo vet in CI will fail only when a new or updated dependency lacks an audit, prompting someone to review it before it can be merged.

CI Examples

cargo-audit and cargo-deny are well suited for running on every pull request. cargo-vet is typically run the same way but requires more initial setup to establish the audit baseline.

name: Audit
on: [pull_request]

jobs:
  deny:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: taiki-e/install-action@v2
        with:
          tool: cargo-deny
      - run: cargo deny check

      - uses: taiki-e/install-action@v2
        with:
          tool: cargo-audit
      - run: cargo audit

deny:
  image: rust:latest
  script:
    - cargo install cargo-deny
    - cargo deny check

name: Vet
on: [pull_request]

jobs:
  vet:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: dtolnay/rust-toolchain@stable
      - uses: taiki-e/install-action@v2
        with:
          tool: cargo-vet
      - run: cargo vet

Reading