Rust RFC Proposes a Security Tab on crates.io for RustSec Advisories

crates.io may soon get a built-in Security tab. A new Rust RFC would add a dedicated “Security” view to crate pages, surfacing known vulnerabilities and “unsound API” advisories sourced from the RustSec advisory database, maintained by the Rust Secure Code Working Group.

Opened in late October 2025 by open source contributor Dirkjan Ochtman, the proposal entered Final Comment Period on December 1, putting it at the last formal step before the Rust project decides whether to merge the RFC. In Rust, RFCs (Requests for Comments) are the mechanism used to publicly debate and document substantial ecosystem changes before they’re accepted and implemented.

Bringing Vulnerability Context into Crate Browsing#

The basic argument is that crates.io is where Rust developers discover and evaluate dependencies, so it should help users assess security and soundness context during the discovery phase, without requiring them to already be running dedicated audit tools.

To set boundaries on what this proposal is (and isn’t) trying to address, Ochtman spells out the scope of risk the Security tab is meant to address:

The Rust ecosystem has a culture of having smaller, focused crates with a clear purpose. As a result, many Rust projects have a large number of dependencies, which increases the risk of introducing problems in the final artifact via the supply chain of dependencies. Actively malicious crates (or crate versions) would be one example of these risks; the crates.io team handles these by deleting them when discovered.

This RFC concerns itself mostly with unintentional vulnerabilities and unsound APIs. An example from the Java ecosystem is the Log4Shell vulnerability in the popular Log4j logging library, when a widely used package exposed affected services to remote code execution attacks.

If accepted, crates.io would add a Security tab that is always present on crate pages. When advisories affect the currently selected version, the tab could be highlighted. Opening the tab would show advisories affecting the crate, including a short summary, affected versions, and links to more information.

The RFC also stresses presentation: popular crates are more likely to have advisories reported simply because they see more use and scrutiny, so the UI should avoid turning “has advisories” into a simplistic quality score.

This first iteration is explicitly UI-only. The RFC does not propose a crates.io API for RustSec advisories. Instead, the registry would reuse RustSec’s existing crates for parsing and querying the advisory database to power the web UI, while downstream consumers would continue using RustSec tooling and the advisory database directly.

Ochtman has already started prototyping the UI. He opened a draft implementation PR against the crates.io codebase as an early take on the Security tab, saying it’s “intentionally light on details” to get feedback on the basic shape while the RFC is still in progress. The PR includes a screenshot showing how advisories might appear in a dedicated Security view on a crate page.

The RFC does float API support as possible future work, but keeps the initial scope narrow.

Maintainers Raise Concerns About Advisory Listings#

The most sensitive thread in the discussion is less about whether advisory data is useful and more about what it means for the official registry UI to display data curated by a volunteer project outside the crates.io team. In the RFC itself, this shows up as a drawback: crates.io would be reflecting “third party” data, and the Secure Code WG’s governance is explicitly called out as relevant context.

"One aspect of RustSec is that it's setup to be able to issue advisories without crate author consent and potentially even when the crate author specifically asks not to," image-rs maintainer Jonathan Behrens commented. "By contrast, my impression is that the project has worked hard to avoid 'picking winners' or otherwise making value value judgements about crates beyond removing obvious spam/malware. There's currently a (perceived?) degree of separation between RustSec and the Rust project that enables this status quo. Displaying advisories directly on a project's crates.io page would break that."

Beherens also raised concerns about how advisories might affect maintainer expectations and user perception, especially around disputed reports or “unmaintained” style advisories.

Tony Arcieri, one of RustSec's maintainers, commented that the database has adopted an official policy around not publishing unmaintained crate advisories if the owner advises against it:

To my knowledge we've never published a security advisory the owner disagrees with, though we can perhaps codify that as a more official policy," Arcieri said. "Generally we like to get advice from crate owners/authors whenever possible when publishing advisories, which is something lacking in other vulnerability reporting mechanisms.

The flipside is there are many abandoned crates with unresponsive authors, and we'd like to avoid a scenario where we can't publish advisories around those because we haven't gotten express owner consent.

RustSec advisories are actively used to flag crates that are unmaintained, which some maintainers see as useful supply chain context and others see as an unfair reputational signal, especially for low-usage hobby projects. Tools that consume RustSec, like cargo-deny, already treat “unmaintained” as a first-class category, which is why ‘unmaintained’ advisories can have a more visible impact when RustSec data gets pulled closer to default workflows.

That disagreement has gotten sharper alongside real-world examples of abandonware risk. In late October, RustSec maintainer Tony Arcieri pointed to TARmageddon (CVE-2025-62518) as a case study in why widely used, unmaintained dependencies can become security incidents, linking to Edera’s write-up of the async-tar vulnerability and its ecosystem impact: RCE Vulnerability Highlights the Challenges of Open Source Abandonware. If crates.io starts surfacing RustSec advisories on crate pages, questions about how “unmaintained” is presented and contextualized will likely be one of the first places this gets contentious.

What's Next#

This proposal is a “move security context earlier” change. Even if you run audits in CI, the adoption decision often happens earlier and more casually, when someone is scanning crates.io and adding a dependency into Cargo.toml. The RFC’s bet is that crates.io is the highest leverage place to surface this information, because it catches developers at the moment they are deciding what to depend on.

If no major objections emerge during Final Comment Period, the RFC can be merged and become an active design. After that, the hard work shifts to implementation and messaging details the RFC intentionally leaves open: what gets emphasized (current vs fixed issues), how affected version ranges are presented, and how crates.io avoids turning advisory history into a lasting reputational signal.