An SBOM generator produces an inventory of components in a format such as CycloneDX or SPDX. An SCA scanner takes an inventory, matches it against vulnerability and license data, and tells you what to fix. Many products do both, but the jobs are different and they fail in different ways.
What a generator does
A generator reads manifests, lockfiles, build output, or an image, and writes a list. Each entry should carry a supplier, a component name, a version, other unique identifiers, and the dependency relationships. Those are the baseline fields named in the NTIA minimum elements, along with the author of the SBOM data and a timestamp.
The output is a document. It makes no judgment about risk. A perfect SBOM can sit next to a critical vulnerability and say nothing about it.
What a scanner does
A scanner starts with the same inventory, whether it builds one or imports yours. Then it does extra work:
- Matches each component and version to vulnerability records
- Reports licenses it can detect
- Ranks findings, sometimes using exploit likelihood or reachability
- Suggests or opens fixes
The accuracy of a scanner depends on two things: how good its inventory is, and how good its vulnerability data and matching are. A weak inventory poisons everything after it.
Where each one fails
Generators fail by omission. A common case is a build that pulls dependencies the generator never sees, such as vendored code or binaries. The NTIA text calls these gaps known unknowns and says an author should state them explicitly when the dependency graph is not fully listed.
Scanners fail by mismatch. A component is reported against the wrong package, or a fixed version is flagged because the data lags. They also fail by volume, listing hundreds of issues with no sense of which matter.
Which do you need?
Use this as a rough guide:
- A customer or regulator asks for an SBOM file: you need a generator, and you need to check its output.
- You need to know what to patch this week: you need a scanner.
- You want both, from one pipeline step: pick a tool that does both, and test each half separately.
How to test the two halves separately
Run the generator on a repository you know well. Compare its list to your lockfile by hand for a sample of fifty components. Then feed that same SBOM into the scanner and review the first twenty findings. If the list is right and the findings are wrong, the problem is matching. If the list is wrong, fix that first.
A related question is whether to scan source or a built artifact. See how often to regenerate an SBOM for the timing side.
Safeguard covers both halves: SBOM and dependency scanning with reachability analysis. You can try it on a repository with the free scan at https://gold.safeguard.sh/scan.
Quick check
Is an SBOM a vulnerability report?
No. An SBOM is an inventory. Vulnerability data is matched against it afterward.
Can I run a scanner without an SBOM?
Usually yes, because the scanner builds an inventory internally. Exporting it as an SBOM is a separate feature worth checking.
Sources
Last reviewed: 19 October 2026.
