cargo audit checks every crate in your Cargo.lock against the RustSec advisory database and prints them in lockfile order, with no sense of which ones your code touches. On a workspace with a few hundred transitive crates that is a list nobody can act on in one sitting, and it also mixes real vulnerabilities with unmaintained, unsound and yanked warnings. Sorting it by whether your code uses the crate turns it into a short first pass.
src/) names the flagged crate directly, in a use, extern crate or path expression. Read these first; the exposure depends on whether you call the affected function, but this is where a real code path can exist.tests/, benches/, examples/ or build.rs use it. The risk is mostly to developer machines and CI, not to the shipped binary (though a build script runs arbitrary code at build time).cargo audit --json in the workspace you ship, then feed it and your source to the triage.--fail-on-imported in CI so a newly vulnerable package your code imports blocks the merge while unreferenced noise does not.cargo tree -i <crate>. If the parent is something you use, treat the finding as reachable.It reads use and path expressions as text. It cannot see macros that expand to a crate path, a crate re-exported under another name, a renamed dependency (package = "..." in Cargo.toml), feature-gated code, or whether the vulnerable function is ever called. It also cannot see the dependency graph, so a crate your code reaches only through another crate is labelled not-referenced. Not used lowers the urgency; it is not a certificate of safety, and this is not a security audit.