Run cargo tree -i crate_name to invert the dependency tree and list every package that depends on that crate. In a workspace, add the workspace flag to see parents across all members. This answers the first triage question for any advisory: why is this code in my build?
Three views you will use
| Command | What it shows |
|---|---|
cargo tree -i crate_name | Reverse dependencies, the parents of a crate |
cargo tree -d | Only crates that appear in more than one version |
cargo tree -e features -i crate_name | Why each feature of a crate is switched on |
The duplicates option implies the inverted view. The edges option takes a comma separated list of kinds: normal, build, dev, features and a few exclusions. The default is normal, build and dev.
An advisory triage workflow
- Take the crate name from the advisory.
- Run the inverted tree. Note whether the path goes through a direct dependency or only through transitive ones.
- Run it again excluding dev dependencies with the no-dev edge setting. If the crate disappears, it is a test only dependency and the risk is much lower.
- Check for build only paths too. A build dependency runs on your machines during compilation, not in the shipped binary, which changes the risk story.
- Record the answer on the ticket: direct, transitive, build only, or dev only.
Reading the output
Packages marked with an asterisk were de-duplicated because their subtree was already printed. Add the no-dedupe option to repeat them if you are cross referencing. Read each chain from the crate you care about up toward your own package. The first link under your own crate is the one you control.
Using features to explain surprises
Sometimes the question is not why a crate is present but why a heavy part of it is compiled. The feature view lists each feature as a node, so you can follow a chain from the leaf up to the dependency that enabled it, often through a parent's default features. That tells you whether turning off default features on one dependency would remove the surface.
Limits
The tree reflects what Cargo resolved. It does not say whether your code calls the vulnerable function. For that you need call level analysis, or a careful read of the advisory's affected functions.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the list of findings shrinks when only reachable ones remain.
Quick check
Does cargo tree show build dependencies?
Yes, by default it shows normal, build and dev edges. Use the edges option to narrow it.
What does an asterisk next to a package mean?
Its dependencies were already printed elsewhere in the tree and were de-duplicated.
Safeguard reachability analysis helps show which vulnerable dependencies are actually called, and you can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
