Ignore an advisory only when no fixed version is available and you can show your application does not hit the affected code. The cargo-audit documentation says to upgrade first and ignore only in that case. Write down the reason, the owner and a date to review.
The decision in order
- Is there a fixed version? If yes, upgrade. Try a conservative update of that one crate before anything else.
- Is the fix blocked by a parent crate? Look at who pulls it in. Updating the parent or patching may work.
- Is the affected code reachable? Read the advisory for the affected function or feature. Check whether your build enables it and whether your code calls it.
- Is the exposure realistic? A flaw in parsing untrusted network input is a different risk from one in a command line flag handler used by developers.
- Can you mitigate elsewhere? Input limits or isolation can reduce risk, but they are compensating controls, not fixes.
Only if you reach a defensible not affected or accepted answer do you ignore.
How to ignore
On the command line, cargo audit takes an ignore option with the advisory ID. Ignores can also live in a configuration file, and cargo deny supports ignores with a reason and an optional expiry. Prefer the tool that lets you attach a reason.
What to record
| Field | Example content |
|---|---|
| Advisory ID | The RUSTSEC identifier |
| Crate and version | What the lockfile holds |
| Decision | Not affected, or risk accepted |
| Reason | Which function or feature, and why it is not used |
| Owner | A named person or team |
| Review date | When the decision comes back |
The project documentation notes that the database records advisories for crates on crates.io and that it is maintained by the Rust Secure Code Working Group. That makes the advisory text your primary evidence. Quote its affected section in your record.
Common mistakes
- Ignoring to get CI green and never coming back.
- Writing no reason, so a successor cannot tell a decision from an accident.
- Treating unmaintained advisories like vulnerabilities, or the reverse. They are different signals.
- Assuming a feature is off because you did not enable it, when another crate did. Check with the feature view in the tree command.
- Copying an ignore from another repository without checking the version.
Audit trail
For regulated customers, an ignore list with reasons and dates is a useful piece of evidence in a vulnerability management process. A bare list is not.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how exploitability evidence supports a decision to defer a fix.
Quick check
Is ignoring the same as fixing?
No. The vulnerable code is still in your build. An ignore is a recorded decision, not a remediation.
How long should an ignore last?
Set an expiry or review date, commonly a few weeks to a quarter depending on severity, and review earlier if the advisory changes.
Safeguard reachability analysis and exploitability evidence can support these decisions, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
