Deputy — Your Rust Dependencies, Owned And Audited

🪩 The Disco Party is MATA's distributed cloud — and Deputy is what keeps its supply chain trustworthy. Every dependency archived, verified, and gated before it can influence a production build.

Deputy is a personally-owned dependency vault for Rust projects. It reads your Cargo.lock, fetches every crate in the transitive closure, verifies each one against the lockfile's SHA-256 checksums, seals them into an encrypted local store, scans the whole set against the RustSec advisory database, and refuses to hand any of it to a build until the audit passes. It is the missing piece between "we use cargo audit" and "we can survive a crates.io outage."

Every Rust project today assumes three things that stopped being reliable years ago. That crates.io will be reachable when the build runs. That the crate you locked yesterday is bit-for-bit the same crate you get today. That "we ran cargo audit in CI" is enough of a supply-chain story. The recent history of typosquatted packages, credential-exfiltration in postinstall scripts, and vendor takedowns says none of those hold up under pressure — and vibe-coded projects that add dependencies without human review make each assumption more fragile. The NIST Secure Software Development Framework has been telling organizations for years that supply-chain choice is a compliance-level concern, not a matter of taste. Deputy is what that concern looks like as a Rust tool.

This article covers why Rust needs a dependency vault at all, how Deputy actually works, and how it compares to the tools most projects reach for today (Dependabot, cargo-vet, Snyk). Source lives on github.com/Remade-With-Rust/deputy; the broader "safe substrate for AI-assisted development" story lives in Safe Vibe Coding — The MATA Skill Folder and the Importance of Remade with Rust. Deputy is also the supply-chain piece under the distributed cloud thesis — you cannot promise a build survives without a single-vendor internet if your dependencies quietly need that vendor to answer.

Why The Rust Supply Chain Needs A Vault

The Rust ecosystem's supply-chain story is not obviously broken — until you look at what actually happens between cargo build and a production deploy. Every dependency in your project is a crate fetched at build time from crates.io, hashed, and cached locally. Between "I locked a version" and "the CI runner is building" the world is the internet: the crate can be re-published under the same version with a new hash, the maintainer's account can be compromised, the crate itself can be marked as vulnerable in RustSec at 2 AM, and crates.io itself can go offline. Any of those turns your reproducible build into "we hope the network is up and nobody is having a bad day."

The Electronic Frontier Foundation's work on software supply chains has been documenting what happens when this trust chain breaks. Typosquatted packages that shadow real crates. Credential-stealing postinstall behavior in seemingly benign utilities. Whole vendor takedowns that pull dependencies your builds depended on out from under you overnight. Every one of those incidents is a case where the build machine treated "fetch from crates.io" as safe by default. Deputy stops treating it that way.

The other pressure on the Rust supply chain is what the last generation of AI-assisted development has done to dependency counts. Vibe-coded projects add crates with impunity — the agent will reach for a niche utility to solve a problem a stdlib call could have handled, and no human will notice. Every one of those additions expands the attack surface without a review pass. Any credible answer needs to run continuously, not only when a developer remembers to trigger it.

How Deputy Works

Deputy sits between cargo and the internet. When your project needs its dependencies, cargo asks Deputy; Deputy has already verified, scanned, and archived every crate the project needs, and hands them back from the local vault. The build proceeds without touching crates.io. The three subsections below walk through the vault, the verification pipeline, and the scanning layer that make that possible.

Vault: Cargo.lock → Encrypted Local Store

Deputy takes Cargo.lock as its input contract. Every crate name and version pin in that lockfile — including the whole transitive closure — is treated as a specification of what the project is allowed to depend on. Deputy fetches each pinned version from crates.io once, verifies the bytes against the lockfile's expected SHA-256, and seals the crate into a content-addressed local vault encrypted with keys you control.

From then on, that vault is the crate source for the project. Every subsequent build reads from the vault, not from the internet. A crates.io outage during a critical deploy stops mattering. A takedown of a specific version stops mattering. A malicious re-publish of an existing version with a different hash — one of the harder attacks to catch by hand — trips Deputy's integrity check before the crate reaches the build. Content-addressed storage also means the vault deduplicates across every project on your machine, so a workspace with a dozen sibling crates does not carry twelve copies of serde.

Verification: SHA-256 + Substitution Detection

Every fetch into the Deputy vault carries a two-step verification pass. First, the raw SHA-256 of the crate must match what Cargo.lock says it should be — that is table stakes and matches what cargo itself does at fetch time. Second, Deputy keeps a history of every hash it has ever seen for a given crate/version combination. If a crate that previously vaulted at one hash tries to vault at a different hash under the same version, Deputy refuses the fetch and surfaces the discrepancy.

That second check is the substitution-detection layer, and it catches attacks the raw Cargo.lock verification does not. If a maintainer's crates.io account is compromised and the attacker re-publishes an older version with a malicious payload — same crate name, same version number, different bytes — Cargo would happily update its cache. Deputy sees the mismatch, halts the build, and hands the decision to a human.

Scanning: RustSec + Risk Signals

Every crate in the Deputy vault is continuously scanned against the RustSec advisory database with CVSS v3.1 severity. Advisories that land after a crate is already in the vault surface as pending audit items on the next build — you find out the version you shipped is now known-vulnerable, and Deputy will not let another build proceed with the affected crates until the advisory is resolved (fixed, waived with justification, or explicitly ignored).

Beyond RustSec, Deputy tracks structural risk signals across the transitive closure: build scripts (build.rs), procedural macros, unsafe usage, and FFI surface. Not every signal is a red flag — plenty of legitimate crates have build scripts or unsafe — but the aggregate lets you see, at a glance, which dependencies expand your attack surface the most for what you get in return. That decision belongs to the humans on the project; Deputy just makes sure the information is present when they look.

Deputy Compared To Existing Tools

Deputy is not trying to replace Dependabot, Snyk, or cargo-vet. It fills a different slot — the archive plus gate slot — and composes with the tools most projects already run. Three comparisons below make the boundary clear.

Deputy vs Dependabot / Renovate — Update vs Archive

Dependabot and Renovate exist to push you toward newer versions of your dependencies. They watch upstream, open PRs against your repo, and ideally you merge and ship. That is a genuinely useful job, and Deputy does not do it. What Dependabot and Renovate do not do is verify, archive, or gate. The moment your build machine trusts crates.io to hand back the same bytes every time, you have accepted the entire modern supply-chain risk surface.

Deputy runs alongside Dependabot. Dependabot proposes updates; Deputy verifies whatever ends up in Cargo.lock and locks it into the vault before it can influence a production build. The Federal Trade Commission's push toward software supply-chain accountability has landed on this shape as best practice — propose, verify, gate — and it maps directly onto the two-tool split.

Deputy vs Snyk / cargo-vet — Scan vs Vault

Snyk and cargo-vet are advisory-scanning tools. Snyk is a hosted product with a broad vulnerability database that spans multiple ecosystems; cargo-vet is a workflow for humans to review dependencies once and record the review in-repo so future audits can trust prior work. Both are useful. Neither archives. Neither survives crates.io going offline. Neither catches a re-publish substitution attack that lands on a version everyone already scanned.

Deputy overlaps with them on the scanning side — RustSec integration covers most of what Snyk would surface for Rust specifically — but the vault plus gate is the piece Snyk and cargo-vet do not provide. If your project already runs one of those, Deputy composes cleanly: the tool that produced the audit signal stays where it is, and Deputy makes sure no build proceeds without the signal being current.

Deputy vs Nothing — The Default You Ship Without

The most common configuration for a Rust project today is Dependabot for updates, cargo audit in CI for scanning, and nothing for verification or gating. That configuration is fine as long as three things stay true: crates.io does not have an outage during a critical deploy, no crate you depend on ever gets re-published with a different hash, and no maintainer account you depend on ever gets compromised. All three have failed in the last three years across other ecosystems. Rust has not had the flagship incident yet — that is not a security posture, that is luck.

Deputy is what you install once so you never have to run that gamble in production. The tooling composes with the rest of MATA's memory-safe substrate — including the Building the New Internet skill folder that curates the stack an AI agent reaches for before the first cargo new, the heap those graphs sit on in rusty_alloc, and the language case in why Rust becomes the standard. The Freedom Guide walkthrough covers the wallet-side pieces the same stack depends on. For long-form field notes on the design and the incidents that motivated it, follow Tim Almond's Medium alongside the Remade with Rust catalogue.