An SBOM misses components when the tool looked at the wrong thing: a manifest instead of a lockfile, one build stage instead of all, source instead of the built artifact, or a scope that filtered them out. Work through the causes below in order, from cheapest check to most expensive.
The checklist
| Check | Symptom | Fix |
|---|---|---|
| Input is a manifest, not a lock or environment | No transitive packages | Use the lockfile or installed environment |
| Scope filter | Test or dev packages absent | Decide if they belong, then change the option |
| Build constraints | Packages for another OS or architecture absent | Generate per target |
| Wrong stage | Build tools missing from a container SBOM | Scan the stage you mean |
| Vendored or copied code | Libraries with no package record | Add them by hand or scan the artifact |
| Shaded or bundled jars | Relocated classes not listed | Compare against the jar contents |
| Offline or private registry | Resolution fails or is skipped | Fix access, then regenerate |
| Tool version | Newer ecosystem features unsupported | Update, and pin the version |
Steps
- Count. Compare the number of components with what a package manager reports for the same project. A big gap points to input source.
- Check one known transitive dependency. Search the SBOM for a package you know is pulled in.
- Check the environment. Run the tool where the release build runs.
- Check scope settings and filters.
- Scan the final artifact and compare to the source based SBOM. Differences show what the build adds or drops.
- Validate the file. A malformed file may be partly ignored by consumers.
Examples from tool documentation
- The Go tool in app mode excludes modules needed only by tests or by packages the program does not import, and applies build constraints from the environment.
- A Docker build SBOM scans only the final stage by default. Earlier stages and the build context are left out unless you set the scan options.
- A directory scan by the .NET tool only finds packages.config files. Modern project files need to be passed in directly.
- Vendoring in Go produces SBOMs without hashes and can break license detection.
When missing means copied
Code copied into your repository has no package manager record. No lockfile scan will find it. Track it as a component by hand, with its source and version, or accept that source and binary analysis will find only some of it.
Try it yourself
Click through it at your own pace, or open it full screen.
Check how many components appear beneath each direct dependency, then use that count as your sanity test on your own file.
Quick check
How do I know the SBOM is complete?
You cannot prove it. Compare against the package manager, a second tool and the built artifact, and record what you checked.
Should I add missing items by hand?
For copied code, yes, with source and version. For package manager items, fix the generator instead.
Safeguard's SBOM and dependency scanning covers manifests, lockfiles and containers, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
