A good SBOM lists every component in your software with accurate names, versions, identifiers and relationships, and it is regenerated whenever the software changes. To evaluate an SBOM tool, generate output on your own projects and compare it with ground truth you build by hand from lockfiles and build files.
Why quality varies
SBOM generators discover components in different ways: reading manifests, parsing lockfiles, inspecting built artifacts or container layers, or watching the build. Each method sees things the others miss. A manifest shows what you declared. A built image shows what shipped. Either alone can be misleading.
What to measure
Completeness. Does the SBOM include transitive dependencies, system packages in containers, and vendored or copied code? Missing components create false comfort.
Accuracy. Are versions correct? A wrong version leads to wrong vulnerability matches in both directions.
Identifiers. Do components carry standard identifiers such as package URLs, so other tools can match them? Names alone cause mismatches.
Relationships. Can you see which component depends on which? Without it, you cannot tell how a risky package entered.
Metadata. Licences, hashes and supplier details matter for compliance and integrity checks.
Format validity. Does the output validate against the schema of the chosen format?
Freshness. Is it generated on every build or only on request?
A practical test
- Pick a small service and build a list of its dependencies by hand.
- Pick one container image and list its system packages using the image's package manager.
- Generate SBOMs with each candidate tool.
- Compare counts, spot-check twenty components for version accuracy and identifiers.
- Validate the files with a schema validator.
Write down differences. Some will be tool bugs and some will be legitimate disagreements about what counts as a component.
Questions for vendors
- Which discovery methods does it use, and can they be combined?
- How does it handle languages with weak lockfile support?
- Can it ingest SBOMs from suppliers and compare them over time?
- Can you attach exploitability statements?
Trade-offs
A perfect SBOM does not exist. Ask whether the tool tells you where it is uncertain. That honesty is worth more than a promise of completeness.
Try it yourself
Open the dependency inventory demo and pick a component. Look for its version, its identifier and the path through which it entered the project.
Click through it at your own pace, or open it full screen.
Where Safeguard fits: SBOM and dependency scanning is generally available, and the free scan at https://gold.safeguard.sh/scan produces an inventory for a repository you can check against your own lockfile.
Quick check
Is a manifest based SBOM enough?
It is a start, but it shows what you declared, not necessarily what shipped. Compare against build output for important products.
How often should an SBOM be regenerated?
On every release at least, and ideally on every build.
Last reviewed: 19 October 2026.
