The cleanest way to close a not reachable finding is to remove the package. If no code needs it, deleting the dependency removes the vulnerability, its future advisories and the work of reviewing them. Use reachability results to find candidates, confirm with your tests and build, then delete.
Why unused packages pile up
Teams add a library for a prototype and keep it. A feature is removed but its import stays in the manifest. A package is replaced by another and the old one is never deleted. Over time the manifest lists packages nobody remembers choosing.
Each one is a standing source of findings.
How to find candidates
- Look at not reachable findings by package. If every finding for a package is unreachable, the package may be unused. If only some are, it is used for something else.
- Use your ecosystem's unused dependency checker. Most ecosystems have one that compares the manifest against imports. Output differs by tool, so read how yours decides.
- Search imports yourself. For a suspect package, search the source for its name and its import path.
- Check build and config files. Some packages are used only by scripts, plugins or build steps, and imports in source will not show them.
Beware the false unused
A package can look unused and still be required.
- It is loaded by name at runtime, by a framework or plugin system.
- It provides a command line tool used in CI.
- It is a peer requirement of another package.
- It is needed for a platform specific build.
This is the same dynamic loading issue that limits static analysis in general. See reflection and reachability.
A safe removal process
- Create a branch and remove the package from the manifest.
- Rebuild and run the full test suite.
- Run the application in a staging environment and exercise main flows.
- Review the lockfile diff to see which indirect packages also left.
- Merge, and watch error rates after release.
Separate dev and runtime
Packages used only in development or tests still matter if they run in CI with access to secrets, but they do not ship to production. Mark them as dev dependencies and triage them on a different track from runtime ones.
What to expect
Fewer packages, a smaller SBOM and a shorter finding list. How much smaller depends entirely on your codebase, so measure before and after rather than expect a number.
Click through it at your own pace, or open it full screen.
Quick check
Is removing a package better than marking it not affected?
Usually yes. Removal ends the exposure and the paperwork. A not affected statement still needs to be maintained.
What if tests pass but I am unsure?
Test coverage may not touch the dynamic path. Stage it and watch logs before a full release.
Safeguard's dependency scanning and SBOM views help you see which packages exist, and the free scan is a quick start.
Last reviewed: 19 October 2026.
