Test completeness with three comparisons: inventory against the lockfiles in the repository, inventory against the built artifact that actually ships, and inventory coverage against a list of every repository. Large mismatches in any of them mean the file describes intent, not reality.
Define complete first
Complete does not mean every byte is explained. The NTIA minimum elements report asks that an SBOM list top level components with their transitive dependencies, and that the author flag known unknowns where the graph stops. So the question is not whether the inventory is perfect. It is whether the gaps are visible and honest.
Test 1: inventory versus lockfiles
Pick three products. For each, count packages in the lockfile and in the inventory.
- Lockfile has packages the inventory lacks: the inventory was built from something else, or is old.
- Inventory has packages the lockfile lacks: possibly built from a different branch, or includes dev tools.
Differences are not automatically a problem. Ask for the reason.
Test 2: inventory versus the shipped artifact
Lockfiles describe what was declared. Containers and bundles hold what was built. Ask for the inventory of the image or package that is deployed, or generate one yourself from it. Operating system packages, runtime layers and copied binaries often appear here and nowhere else.
| Comparison | Catches | Misses |
|---|---|---|
| Versus lockfile | Stale inventory, wrong branch | Vendored code, OS layers |
| Versus built artifact | OS packages, bundled libraries | Dependencies of tools used only in CI |
| Versus repo list | Whole repositories nobody inventoried | Quality inside each repo |
Test 3: inventory versus the repository list
Get the list of repositories from the source host, not from the seller's summary. Then ask which of them have an inventory. A seller who covers the main product but not the internal tools, the mobile app or the data pipeline has a coverage gap even if each file is good.
Test 4: spot check a few components
Choose five components at random. For each, confirm the version in the artifact, the license field, and whether any known vulnerability record exists. Five checks will not prove completeness, but one bad result changes your confidence quickly.
What good looks like
- Timestamps are recent and tied to a release.
- Every product has a file.
- Unknowns are labelled, not hidden.
- The seller can explain each mismatch within a day.
What to do with mismatches
Write each one in a gap list with a size estimate and an owner. Do not reject the inventory outright. A short list of explained gaps is normal. A long list nobody can explain is the finding.
Safeguard's SBOM and dependency scanning can produce an inventory from a repository or an image, which makes the comparison above quicker. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how the inventory separates direct and transitive packages, since that is the first split to check against a lockfile.
Quick check
Can I trust an inventory that matches the lockfile exactly?
It is a good sign for declared dependencies. It says nothing about vendored code, base image packages or anything outside the lockfile, so still compare against the built artifact.
How many repositories should I sample?
Cover every product, then sample within each. If the estate is large, ask the seller for coverage numbers and verify a handful yourself.
Sources
Last reviewed: 19 October 2026.
