Only partly. An SBOM lists the components in your software, but it does not show whether your code calls them. To find unused dependencies, use the SBOM as the candidate list and confirm with usage analysis from your language tooling, then remove in small steps.
What an SBOM can and cannot say
An SBOM records what is declared, resolved or installed. A library can appear in it because someone added it for a feature that was later deleted, or because a test helper was copied into the runtime scope. The SBOM cannot see that, because it is an inventory and not a call analysis.
What it does give you is a complete list to review and a way to count: how many components, how many are direct, how many are transitive. A large list is not a problem on its own, but each entry is something to patch and explain.
Tools that check usage
Different ecosystems have their own checks.
- Go: the tidy command removes requirements on modules that do not provide any relevant packages, and adds missing entries to go.sum while removing unnecessary ones.
- Maven: the dependency analyze goal sorts dependencies into used and declared, used and undeclared, and unused and declared. The plugin notes it works at bytecode level and has limitations, so treat its output as a lead, not a verdict.
- Other languages: most have a similar linter or checker. Use whichever your team already trusts.
A safe pruning routine
- Export the SBOM for the service and sort direct dependencies by owner.
- Run the usage check for your ecosystem and list the unused and declared entries.
- Check for dynamic use. Plugins loaded by name, reflection, annotation processors and runtime configuration can hide real use from static checks.
- Remove one batch at a time, then run the tests and a build.
- Regenerate the SBOM and confirm the component, and any transitive ones it brought, are gone.
- Record the change so reviewers know why the list shrank.
Why bother
| Benefit | Why it follows |
|---|---|
| Fewer advisories to triage | Unused code still triggers matches |
| Smaller upgrade surface | Fewer major version moves later |
| Cleaner SBOMs for customers | Less to explain |
The first row deserves a caveat. A vulnerable library that your code never loads is still reported by a scanner that matches on versions. Removing it ends the report. Where you cannot remove it, reachability analysis helps you show that the vulnerable code path is not called, which is a different claim from "not installed".
Try it yourself
Click through it at your own pace, or open it full screen. Notice how findings change once reachability is taken into account.
Safeguard combines SBOM and dependency scanning with reachability analysis. A free scan shows what a repository declares and which findings matter.
Quick check
Is a bigger SBOM always worse?
No. Size alone is not risk. But every component is something to patch and justify, so unused ones are worth removing.
Can I trust an automated unused dependency report?
Treat it as a lead. Dynamic loading and reflection can hide real use, so test after each removal.
Sources
- Go modules reference
- Apache Maven Dependency Plugin, dependency:analyze
- CycloneDX, Software Bill of Materials capabilities
Last reviewed: 19 October 2026.
