cargo-auditable

What it is #

cargo-auditable is a small Cargo subcommand that embeds the build’s dependency list into the compiled binary. The recorded data is essentially the Cargo.lock content (registry, package name, version, source) plus the dependency graph, serialised as JSON, compressed, and stored in a dedicated section of the executable (ELF, Mach-O, or PE).

A companion tool, rust-audit-info, extracts that section from any auditable-built binary and emits the dependency list. Vulnerability scanners can then run against the extracted data, giving a path to “what crates are in this binary” without needing the original source tree or Cargo.lock.

Trust model #

cargo-auditable does not sign anything. The embedded data is plain metadata that the build tool wrote into the artefact, and a sufficiently motivated builder could populate the section with misleading content. In honest-build settings (you trust the party who produced the binary), the data is a faithful record of what was linked in. In adversarial settings the data is useful only when paired with a signed attestation (in-toto, SLSA provenance) that binds the binary to a verifiable build process.

What cargo-auditable records is which crates were resolved into the build, not whether those crates are safe.

Comparison to OpenVet #

cargo-auditable and OpenVet operate on different artefacts and answer different questions.

What is recorded. cargo-auditable records a parseable dependency list inside a compiled binary. OpenVet records signed claims about specific source packages, hosted in logs and looked up by registry, package, version, and hash.

Crypto guarantees. cargo-auditable’s embedded data is unsigned; its integrity rests on trust in the builder. OpenVet audits are individually signed by their authors and live in append-only logs signed by publishers; verification is end-to-end on the consumer side.

Scope. cargo-auditable is Rust-only and operates at the binary level. OpenVet covers Cargo, npm, PyPI, Go modules, and RubyGems at the source-package level.

Using alongside OpenVet #

The two are highly complementary. cargo-auditable answers “what crates are inside this binary”; OpenVet answers “what has been said about those crates by people I trust”.

Post-hoc audit lookup. Given a binary built with cargo-auditable, a consumer can extract the embedded dependency list and look up OpenVet audits for every crate at the recorded version. This makes it possible to apply audit-based policy to artefacts long after they were built.

Where binary distribution meets source audit. Rust applications often ship as standalone binaries with no Cargo.lock alongside. cargo-auditable makes the lockfile information recoverable from the artefact itself, which is exactly the data OpenVet’s lookups need.

Honest builds vs adversarial builds. Without a signed provenance attestation, cargo-auditable’s data must be taken on the builder’s word. In an honest-build setting (your CI, a vendor you trust), that is enough to drive an OpenVet evaluation. In an adversarial setting, pair the embedded data with an in-toto or SLSA attestation that binds the binary to the build process; the auditor verifying that attestation can then re-surface the embedded dependency list as part of an OpenVet claim about the binary.