On February 8, 2021, AWS, Google, Huawei, Microsoft, and Mozilla formally established the Rust Foundation as an independent 501(c)(6) with an initial $1 million funding commitment and a board seat structure that moved stewardship of the Rust trademark, crates.io infrastructure, and core project governance out of Mozilla Corporation — where it had lived since Rust's 1.0 release in May 2015 — and into a dedicated nonprofit. The formation arrived four months after Mozilla's August 11, 2020 layoffs cut a majority of the Rust compiler team employed there, creating a governance crisis that the Foundation was specifically chartered to resolve. From a security standpoint, the Foundation changed three things that matter: who pays for crates.io's infrastructure and security engineering, who holds the trademark (and therefore can sue over confusing fakes), and who coordinates responsible disclosure for the Rust Security Response WG. This post examines what each of those changes has meant for Rust's supply chain security posture since.
Why did Rust need a foundation for security reasons?
Rust needed a foundation because the ecosystem's critical infrastructure — crates.io, the docs.rs builder, the release signing keys, the RustSec advisory database — was running on donated resources and volunteer labor with no legal entity able to sign vendor contracts, hire security engineers, or hold cryptographic keys in a continuity-preserving way. When Mozilla reduced Rust investment in 2020, the ecosystem discovered it had no independent path to pay AWS invoices for crates.io hosting. That is a supply chain risk at the root: if the registry goes down, every downstream build in the ecosystem fails, and if the signing keys are lost, every consumer has to re-pin trust. The Foundation's formation gave the project a legal counterparty that could own those assets, contract with CDN providers, hire security staff, and represent the project in standards bodies like the OpenSSF.
What security engineering capacity did the Foundation fund?
The Foundation funded the first dedicated security-focused engineering roles in Rust's history. In March 2022 it hired its first Security Engineer and in 2023 funded three additional positions under the "Security Initiative." Those hires produced concrete deliverables: the crates.io malware scanning pipeline announced in October 2023, hardened publish workflows with required 2FA, the audit of third-party dependencies in the official compiler build, and the threat model document for the Rust Project infrastructure published in 2023. Before 2021, any of that work depended on volunteers or employer donations. After 2021, there was a budget line, an accountable staff member, and a reporting structure. That is the difference between "we should improve this" and "this is Q3 deliverable with a name against it."
How did crates.io security change after foundation formation?
crates.io security changed through a series of hardening steps that would have been politically and logistically difficult without a funded entity. Mandatory 2FA for crate owners rolled out in August 2023 (RFC 3199), with token-based publishing replacing username-password publishing for CI. The registry adopted short-lived, scoped API tokens. Abuse reporting, DMCA handling, and takedown workflows became documented policies executed by Foundation staff rather than ad-hoc maintainer decisions. Crates.io began publishing its index over a CDN with verifiable Merkle-style integrity properties, and the cargo client gained cargo-audit integration (already community-maintained via RustSec) as part of the default workflow. Most importantly, the Foundation can now sign SLSA-style provenance on rustc and cargo releases because it holds the keys in a continuity-preserving way.
What did the Foundation change for responsible disclosure?
The Foundation created the Security Response Working Group as a continuous, funded function rather than a rotating volunteer duty, with clear channels at security@rust-lang.org and a published process modeled on the Linux kernel's. Vulnerabilities like CVE-2022-21658 (a TOCTOU in std::fs::remove_dir_all) and CVE-2024-24576 (the BatBadBut Windows command argument-escaping issue affecting std::process::Command) were coordinated through this group with embargoed patches distributed to downstream vendors before public disclosure. Before the Foundation, embargo handling for Rust-language vulnerabilities was improvisational, and disclosures to major downstream consumers (Microsoft, AWS, Firefox) happened through informal channels. After the Foundation, those relationships are formalized, auditable, and survive any individual's departure.
What did the 2023 trademark controversy reveal?
The 2023 trademark policy proposal revealed a governance tension that is inherent to any foundation managing a project with a large community — and how the Foundation responded is informative for security. In April 2023, the Foundation published a draft trademark policy that many community members viewed as overreaching (restrictions on community project naming, conference naming). The response was a public comment period, extensive revisions, and ultimately a more permissive policy published in September 2023. For security, this matters because the trademark is the legal primitive that lets the Foundation pursue imposters — crates named to look official, phishing websites pretending to be rust-lang.org, malicious packages squatting on near-typo names. A permissive but clear trademark policy enables anti-typosquatting enforcement. An incoherent or community-hostile one doesn't.
# Modern crates.io publish workflow (post-2023)
# Requires 2FA-authenticated session or scoped token
cargo login --registry crates-io <SCOPED_TOKEN>
cargo publish --token $CARGO_TOKEN --registry crates-io
# Verify provenance (when SLSA provenance matures)
cargo verify --provenance
The fact that the above is possible — scoped tokens, CI-bound publishing, verifiable provenance — is downstream of the Foundation's existence.
What downstream security guarantees does this actually produce?
The downstream guarantees are modest but real. Consumers of Rust crates get a registry with mandatory 2FA on maintainer accounts, scoped publish tokens, malware scanning on new versions, and a responsive security team with a budget. They do not yet get signed packages (crates.io does not publish per-crate signatures the way sigstore does for some ecosystems), reproducible builds across the ecosystem (this is a per-crate property), or a formal SLSA level on the full toolchain — though work is ongoing. Rust's supply chain security guarantees are better than Python's, roughly comparable to modern Go's (which has the checksum database), and still behind the theoretical ideal. The Foundation's continued funding is what determines whether the gap closes or widens.
How Safeguard Helps
Safeguard integrates with the RustSec advisory database and crates.io metadata to give you real-time exposure reporting for every Rust dependency in your services, including transitive pulls. Reachability analysis narrows Rust advisories to only the ones whose vulnerable code paths your binary actually compiles in, so an advisory against time or chrono stops generating false-positive noise. Griffin AI summarizes crate maintainer posture — 2FA status, publish frequency, known incidents — as part of your dependency review. SBOM ingestion handles CycloneDX output from cargo-sbom and syft uniformly. Policy gates can enforce minimum crate age, require provenance where available, and block the build when a critical RustSec advisory has no mitigation applied.