In deny.toml under [advisories], set yanked to deny or warn, choose a scope for unmaintained (all, workspace, transitive or none), and record every exception in ignore with a reason. The defaults are yanked = "warn" and unmaintained = "all", so check what your pipeline really enforces.
What each key does
| Key | Values | Default |
|---|---|---|
db-urls | list of advisory database URLs | the RustSec advisory-db repository |
yanked | deny, warn, allow | warn |
unmaintained | all, workspace, transitive, none | all |
ignore | advisory IDs, crate@version strings, or tables | empty |
The unmaintained scopes matter. Workspace means only direct dependencies of your workspace crates. Transitive means only the dependencies those pull in. All means both.
Yanked versions
A yanked version is one its owner marked as broken or unsafe to start new dependencies on. Existing lockfiles keep working, which is why a yanked crate can sit in your graph unnoticed. Setting yanked = "deny" turns that into a visible failure so someone updates the lock.
Yanking does not delete code and is not an advisory by itself, so treat it as a prompt to look, not proof of a vulnerability.
Unmaintained crates
An unmaintained advisory says a crate lacks an active maintainer. That is a risk signal, not a vulnerability. A reasonable policy: deny unmaintained for direct dependencies you chose, and warn for transitive ones you cannot easily replace.
[advisories]
yanked = "deny"
unmaintained = "workspace"
ignore = [
{ id = "RUSTSEC-0000-0000", reason = "not reachable, replacement tracked in issue 123" },
]
The ID above is a placeholder. Never copy an ID without checking the real advisory.
Writing good ignores
The ignore list accepts a reason, and tables can also carry an expiry duration. Use both. An ignore with no reason is a future mystery, and one with no expiry never gets revisited.
- Read the advisory and the patched version range.
- Try the upgrade first. Often a conservative update of one crate fixes it.
- If you must ignore, write why the code path is not affected.
- Set an expiry so the decision comes back for review.
- Review the ignore list in the same meeting as your other risk acceptances.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how findings move from open to accepted or fixed, and what evidence is kept.
Quick check
Should I ever set yanked to allow?
Rarely. Allow only prints a note. Use it temporarily during a migration, and put a date on it.
Does an unmaintained advisory mean I am vulnerable?
Not by itself. It means nobody is actively fixing the crate, so future bugs may stay open.
Safeguard reachability analysis can help decide whether an advisory affects code you actually call, and you can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
