Skip to content

Adding a crates.io Security tab #3872

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 8 commits into
base: master
Choose a base branch
from
+155 −0
Open

Adding a crates.io Security tab #3872

Changes from 1 commit
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
80e534c
Initial draft for crates-io-security
djc Oct 6, 2025
d75a3e0
Appease VS Code formatting
djc Oct 28, 2025
2bc2a45
Attempt better separation of goals and proposed UI
djc Oct 28, 2025
4eb1e35
Add lib.rs audit pages as prior art
djc Oct 28, 2025
83214f1
Add note on sending feedback to RustSec
djc Oct 28, 2025
09f2a1f
Clarify difference between malicious and unintentional issues
djc Nov 3, 2025
8621245
Clarify goals with single crate vs dependencies
djc Nov 3, 2025
1f931f5
Add future work section on SECURITY.md files
djc Nov 3, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
130 changes: 130 additions & 0 deletions text/3872-crates-io-security.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,130 @@
- Feature Name: crates-io-security
- Start Date: 2025-10-27
- RFC PR: [rust-lang/rfcs#3872](https://github.com/rust-lang/rfcs/pull/3872)
- Rust Issue: [rust-lang/rust#3872](https://github.com/rust-lang/rust/issues/3872)

# Summary
[summary]: #summary

This RFC proposes that crates.io should provide insight into vulnerabilities and unsound
API surface based on the RustSec advisory database.

# Motivation
[motivation]: #motivation

One of the roles that crates.io serves for Rust developers is as a discovery mechanism for library
packages. As such, it is important that users can quickly assess the quality of a given crate,
including security considerations such as unsound code/API or known vulnerabilities.
The RustSec advisory database is a curated database of security advisories for Rust crates,
which tracks known vulnerabilities, unsound code, and maintenance status of crates.
Comment on lines +20 to +21
Copy link

@fintelia fintelia Nov 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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. 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.

I think there's value in empowering maintainers to notify their users that some old crate versions contain vulnerabilities. But I'm far less comfortable with having any disputed advisory becoming a permanent badge on a crate's project page or the risk of having RustSec's timelines become de-facto support SLAs that all maintainers are expected to adhere to.

Putting maintainers in control would align with open source projects (including Rust!) becoming CVE numbering authorities so that they can define what counts as a security vulnerability and control what CVEs are filed.

Copy link

@tarcieri tarcieri Nov 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RustSec has adopted an official policy around not publishing unmaintained crate advisories if the owner advises against it, and 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. 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.

Copy link

@fintelia fintelia Nov 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The messaging in the unsoundness/security advisories (i.e. the ones about stuff other than being unmaintained) that I've seen had much more a tone of "we're going to publish this advisory regardless, but are willing to delay a bit if you think you can get a fix out soon". In fact this policy seems to say that advisories should be published even when disputed:

If the upstream project disputes the existence of the issue, and it doesn't have a high severity, informational = "unsound" should be used

It would be a welcome change to clarify that advisories won't be filed if the crate author disputes them or asks not to.

Unmaintained advisories won't be displayed initially, but they've driven me to have an increasingly negative opinion of rustsec. Having a list of unmaintained crates implies that users of every other crate are entitled to prompt responses to issues or at least continued development. Which goes against the "THE SOFTWARE IS PROVIDED AS IS" that's in every OSS license. And when the typical unmaintained advisory is for some random library with approximately zero downloads/usage that's on version 0.1.2 and hasn't had a release in 8 years, it all feels rather mean-spirited to track down the original author to ask them to admit their crate is unmaintained. Doubly so if it's an employee reaching out to an unpaid volunteer. Even the terminology could've been softened to "end-of-life" which is how I've generally seen it described in commercial marketing.

Copy link

@tarcieri tarcieri Nov 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You seem to be simultaneously accusing RustSec of not getting maintainer input and “track(ing) down the original author to ask them to admit their crate is unmaintained” which you call “mean spirited”.

You can’t have it both ways: to get maintainer consent on advisories we have to “track down” the maintainers and ask.

Regarding unmaintained crates, I think the recent TARmageddon vulnerability illustrates the security response problems unmaintained crates present, but also popular unmaintained libraries remain a popular target for spearphishing attacks, of which we’ve seen many recently in the npm ecosystem.

Copy link

@fintelia fintelia Nov 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I believe it is simultaneously true that there are cases where rustsec should seek (and honor) maintainer input and other cases where rustsec shouldn't consider issuing an advisory at all. Hence my qualification that that unmaintained advisories can feel mean-spirited when directed at crates with approximately zero downloads/usage.

But I think I've made my position clear and this now is sufficient off topic, so please feel free to resolve this thread.


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.

We've seen an increasing number of security issues via transitive dependencies:

* In 2024, some releases of the popular xz-utils package (written in C) contained
a [malicious backdoor] affecting OpenSSH servers running on the local system.
* In 2025, a phishing campaign [targeted crates.io users] using the `rustfoundation.dev` domain
name to impersonate the Rust Foundation and steal maintainer's credentials.

While known actively malicious crates would be deleted from crates.io by the responsible team,
unintentional vulnerabilities and unsound APIs can still pose a risk to Rust developers.

The Open Source Security Foundation (OpenSSF) has enumerated [Principles for Package Repository
Security]; while crates.io already addresses many of these, one of these is:

> The package repository warns of known security vulnerabilities in dependencies in the package
> repository UI.
The RustSec advisory database tooling already supports exporting advisories in the OSV format.

[malicious backdoor]: https://en.wikipedia.org/wiki/XZ_Utils_backdoor
[targeted crates.io users]: https://blog.rust-lang.org/2025/09/12/crates-io-phishing-campaign/
[Principles for Package Repository Security]: https://repos.openssf.org/principles-for-package-repository-security.html

# Guide-level explanation
[guide-level-explanation]: #guide-level-explanation

The crates.io website will display information about known vulnerabilities and unsound APIs.
This might take the form of a Security tab on a crate's page. If there are known vulnerabilities
for the currently selected version, the tab might be highlighted. The Security tab will be
there whether there are existing advisories for a crate or not, and the linked page will show
a message indicating that there are no published advisories if that is the case.

Opening the Security tab for a crate should show a list of advisories that affect the crate,
including a summary of the issue, a list of affected versions, and links to more information.
Care should be taken to ensure that the mere existence of past vulnerabilities does not negatively
impact the perceived quality of a crate; very popular crates are much more likely to have
vulnerabilities reported against them, simply due to their popularity and the amount of scrutiny.

The Security tab should give Rust developers a quick overview of the security status of a crate,
and allow them to make informed decisions about whether to use the crate in their projects.

While this information is available today via the RustSec website (including feeds that can
automatically be consumed by tooling), having this information directly on crates.io would
make it accessible and visible to a wider audience.

# Reference-level explanation
[reference-level-explanation]: #reference-level-explanation

The RustSec project publishes a number of Rust crates that can be used to parse and query the
advisory database, which can be reused in the crates.io codebase. For now, crates.io will only
display advisories in the UI; we will not be adding API to query RustSec advisories. Downstream
users who want to consume this data can use the RustSec crates and the [advisory-db repository]
directly.

[advisory-db repository]: https://github.com/RustSec/advisory-db

# Drawbacks
[drawbacks]: #drawbacks

The RustSec project is maintained by an independent team of volunteers, so the crates.io Security
tab will be reflecting data that is maintained by what amounts to a kind of third party.
The Leadership Council has an [ongoing discussion] on governance for the Secure Code WG that
governs the RustSec project, which might be relevant to this proposal.

Rust developers might be scared off of using crates that have known vulnerabilities, even if
those vulnerabilities are not relevant to their use case, or have been fixed in later versions.
This seems like a reasonable trade-off to me -- we should allow informed users to make decisions
that are best for their projects.

[ongoing discussion]: https://github.com/rust-lang/leadership-council/issues/140

# Rationale and alternatives
[rationale-and-alternatives]: #rationale-and-alternatives

crates.io is the official package repository for the Rust ecosystem, so sharing important security
context via this interface seems like an effective way to make it accessible to a wide audience.

Widely used tools like [cargo-audit] and [cargo-deny] already provide a way to check for
security-sensitive issues in a Rust project's dependencies, but these tools are opt-in and require
users to be aware of them and to run them. They are also more focused on auditing a project's
existing dependencies rather than helping inform users in the discovery phase.

Alternatively, we might make the RustSec advisory database available directly via cargo. This
seems mostly unrelated to what crates.io does, and seems like an interesting future possibility.

[cargo-audit]: https://crates.io/crates/cargo-audit
[cargo-deny]: https://crates.io/crates/cargo-deny

# Prior art
[prior-art]: #prior-art

Neither npm nor PyPI currently seem to provide support for displaying security advisories.

# Unresolved questions
[unresolved-questions]: #unresolved-questions

This seems like a relatively straightforward feature with a limited scope. The main questions
are about the desirability of the feature, the implementation approach, and the governance
of the source data.

# Future possibilities
Copy link
Contributor

@epage epage Oct 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reporting on provenance is related: https://lawngno.me/blog/2024/06/10/divine-provenance.html

The challenge there is setting the right tone of "there are divergences, this needs further investigation" rather than "this is bad!". Unsure if that can be satisfied on a Security tab, or if it needs to be a Health tab or maybe an Insights tab?

[future-possibilities]: #future-possibilities

In the future, it would be valuable if lockfile updates exposed open vulnerabilities in a
project's dependency graph in the Cargo CLI, for example on `cargo update` or `cargo check`.

crates.io could extend its existing API to query advisories for a given crate.