The RustSec advisory database: security records for crates.io packages

What the repository holds

The RustSec Advisory Database is a repository of security advisories filed against Rust crates published via crates.io, and a human readable version of the database is published at rustsec.org/advisories.

The split between the repository and the website matters for anyone using this. The repository is the source of truth, a directory of files that can be read with a text editor, diffed, mirrored and consumed by machines. The website is the rendered view for people who want to search for a crate rather than for a file.

The data is also exported to the OSV format, in a separate branch of the same repository, and all of it is available on osv.dev and through that project's API. The GitHub Advisory Database imports the RustSec advisories, which is why a Rust crate can turn up in a GitHub security alert even though nobody filed a GitHub advisory for it.

That export path is what makes the project larger than its own website. The data reaches tools that have no particular interest in Rust, and the list of consumers in the README includes cargo-audit, which audits a Cargo.lock for crates with security vulnerabilities, and cargo-deny, which does that and also limits which dependencies, licences and sources you use and detects multiple versions of the same package in the tree. Trivy consumes it through OSV, and Dependabot works from the GitHub Advisory Database, which imports from here.

The last push to the repository was on 2026-10-14, and the project describes itself as maintained through the first quarter of 2026.

Filing an advisory, and the order of operations

The Create an Advisory section is short and the ordering in it is the part to follow.

If you discover a vulnerability, you report it upstream according to their security policy. Afterwards, you can create an advisory by opening a pull request using the template. The contributing document has more detail, and there is a separate guide to read before filing an advisory for an unmaintained crate.

The order is the whole policy. A vulnerability that is reported to the advisory database before it is reported to the maintainer is a public disclosure, and the database is not the place to make one. The maintainer gets the chance to fix it, and the advisory then records the result.

The separate guide for unmaintained crates is the other special case. An unmaintained crate is not a vulnerable one, it is a crate nobody is fixing, and filing that as an advisory is a different kind of statement, so the project has a document explaining when and how to do it.

For the maintainers of the database itself, there is a maintainers guide, a duplicate identifier guard as a directory in the repository root, and a support configuration file. The guard is the interesting one, because advisory identifiers follow a predictable pattern and a duplicated one would break the tooling that indexes them.

The template itself is the thing a contributor actually fills in, and the README says the template comments should be deleted before submitting, as well as any unused fields, which keeps the stored advisories consistent with one another.

The advisory format: TOML header, Markdown body

Advisories are formatted in Markdown with TOML front matter, and the README says the above TOML section is followed by the long description in Markdown format.

So an advisory file is a Markdown document with a machine readable header, which is a good design for a database that is both read by people and parsed by tools. The prose is where the detail goes, and the header is where the facts that a scanner needs go.

The header schema is long, and most of it is optional, but the required parts are the ones to understand. The identifier is mandatory and is assigned as an RUSTSEC-YYYY-NNNN form, and the template asks contributors to use a placeholder form in pull requests so the number is not claimed by mistake. The affected crate name is mandatory, and the disclosure date is mandatory and is an RFC 3339 date.

The version information is where the tooling bites. The patched versions are mandatory, and every selector Cargo supports is supported there, which means a range can be written the same way it would be in a dependency specification. There is also an optional unaffected list for versions that were never vulnerable, which exists because a crate can have a version range that was never affected at all.

The affected functions table is a finer grain still. It maps canonical paths to vulnerable functions to the version requirements that apply to each path, and the comment explains why, that a function may have been renamed between versions, so the path to it changed while the vulnerability did not.

[affected.functions]
"mycrate::MyType::vulnerable_function" = ["< 1.2.0, >= 1.1.0"]

[versions]
patched = [">= 1.2.0"]

# Versions which were never vulnerable (optional)
#unaffected = ["< 1.1.0"]

The fields that carry the meaning

Several of the header fields are worth reading closely, because they are the ones that change what a scanner reports.

The informational field is the one RustSec has that most advisory databases do not. It marks the advisory as one of three kinds, unsound for soundness issues, unmaintained for crates that are no longer maintained, and notice for other informational notices. An unmaintained advisory is not a vulnerability and does not have a fix, and the versions section says so explicitly, telling you to use an empty patched list in that case.

The categories field is a controlled vocabulary, with a crypto-failure example, and the link goes to the enumeration in the rustsec documentation.

The aliases and related fields are how a record is tied to the wider world. Aliases are vulnerability aliases such as CVE identifiers, and the template marks them as optional but recommended, and related is for advisories that are connected without being the same issue, for instance a CVE for a C library that a system crate wraps.

The license field is the exception to the rest of the schema. The default is CC0-1.0, and the accepted values are CC0-1.0 and CC-BY-4.0, and the comment explains that CC-BY-4.0 requires the url field to contain the link to the source advisory, and that it should only be used for advisories imported from the GitHub Advisory Database.

The affected section carries the architecture and operating system lists, and the guidance is to use them only when the vulnerability is specific to one, for example a bug in x86 assembly or in a binding to a Windows specific API.

The licensing model, and the exception

The licence section is short and it is a two part answer.

All content in the repository is placed in the public domain, except where otherwise specified. The exceptions are the advisories imported from the GitHub Advisory Database, which are placed under the Creative Commons Attribution 4.0 licence, and they contain a license field explicitly indicating their licence and a url field pointing to the original advisory for proper attribution.

The reasoning is straightforward. The advisories that the RustSec project writes itself are public domain because the information is meant to be freely usable by scanners and by people. The ones imported from GitHub are not the RustSec project's to license, so they carry the licence of the original and point back at it.

The same split is what the license field in the header is for, and it is why the schema restricts the accepted values to those two identifiers. The attribution requirement is a condition, not a formality, which is why the comment says the url field must contain the link to the source advisory when the CC-BY-4.0 licence is used.

The repository also carries a licences directory with the text of the two licences, so the terms travel with the data rather than living only in a readme.

What this database is, and what it is not

The comparison worth making is with the GitHub Advisory Database alone, since the two overlap and the difference is what the RustSec project adds.

The GitHub Advisory Database is a general database covering many ecosystems, and it imports the RustSec advisories, so a Rust vulnerability filed here shows up there. What RustSec has that a general database does not is the informational class of advisory. A crate that is unmaintained, or that is unsound in a way that is a soundness issue rather than a memory safety one, gets a record here, and a scanner can act on it. The category vocabulary, with values such as crypto-failure, is also specific to this project.

What the database is not is a place to look up whether a version of a crate is safe in general. It records published advisories, so a crate with no advisory is not thereby proven safe, and the version selectors are what the tools act on, which means a wide patched range will make a scanner flag releases that were never affected.

The consumption story is the part that makes this practical. cargo-audit reads it for a Cargo.lock. cargo-deny reads it and adds dependency, licence and source policy on top. Trivy reads the OSV export for container images. Dependabot reads the GitHub copy and can raise the pull request that fixes it. So the same record ends up either blocking a build or opening a pull request, depending on which tool you point at it.

For a maintainer, the practical entry point is the two documents at the root, the contributing guide and the example advisory, and the rule about reporting upstream first is the one that decides whether your pull request is welcome.

Editorial conclusion

Adopt the RustSec database, or a tool that reads it, if you ship Rust binaries, because it is the place where crate specific advisories live, including the ones no CVE exists for. Do not file an advisory before you have reported the problem upstream, because the project asks for that order and a record that was never disclosed to the maintainer is a disclosure in itself. Before you rely on the machine readable fields, read the schema, since the patched version selector and the affected functions are what the tooling acts on, and a version range that is too wide will make a tool flag releases that were never vulnerable.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. rustsec/advisory-db on GitHub