How do I prove a dependency is unused before removing it?

Check three things: who declares the dependency, whether any code imports it, and whether anything loads it by name at runtime. If the answer to all three is nobody, remove it, run the tests, and rescan. Removal is the cheapest vulnerability fix because it leaves nothing to patch.

Step 1: who requires it

Every ecosystem has a command that answers why a package is present. Use the one for yours.

The npm documentation describes explain as printing the chain of dependencies causing a given package to be installed in the current project. The Cargo documentation describes the invert option as showing reverse dependencies. Composer describes depends as telling you which other packages depend on a certain package, and notes that dev requirements count only for the root package.

If another package requires it, you cannot simply delete it. You are in the transitive case, and removal means removing or replacing the parent.

Step 2: does your code import it

If the answer to step 1 shows only your own manifest, search the source for imports. Search across all languages in the repository, tests, scripts and build files, not only the main source folder. A dependency used only in tests is a dev dependency, not an unused one.

Watch for indirect use:

1. Plugins or loaders that read module names from configuration files.
2. Build tools that call a package by name from a script.
3. Dynamic imports built from strings.
4. Frameworks that auto discover packages by convention.
5. Command line tools the package provides, called in CI.

Step 3: remove it on a branch and run everything

Remove the declaration, regenerate the lock file, and run the build, the tests and a smoke test. A failure in a rarely used path is possible, so check the code path list from step 2.

npm uninstall oldpackage
go mod tidy
composer remove vendor/oldpackage

The Go reference notes that go mod tidy and related commands operate on the main module. For a Rust crate, remove the line from Cargo.toml and rebuild. Compare the lock file before and after. Only the removed package and anything that was used solely by it should disappear.

Step 4: confirm the finding is gone

Rescan the built artifact. If the vulnerable package still appears, something else brings it in. Go back to step 1 for that path. See also the related guide on removing unused dependencies before you triage them.

When you cannot prove it

If you cannot show a package is unused, do not delete on hope. Options: keep it and mitigate, wrap it with a narrow adapter, replace it, or run in a staging environment with extra logging for a defined period. Also consider reachability. A package that is present but whose vulnerable function is never called is a different risk than one in constant use, though it is still worth removing on a schedule.

Try it yourself

Click through it at your own pace, or open it full screen. See how findings in code that is never called are separated from the ones that matter first.

Where Safeguard fits

Safeguard scans dependencies, runs reachability analysis to show which findings your code can actually reach, and can open fix pull requests through autonomous remediation. That last feature is off by default and every category starts on Manual, so a person approves each change. You can try a free scan on a repository first.

Quick check

Sources

• npm explain documentation
• cargo tree, The Cargo Book
• Composer command line reference, depends
• Go modules reference

Last reviewed: 19 October 2026.