Why your SBOM finds zero vulnerabilities

“No findings” is a result about matching, not about safety

A vulnerability matcher compares component identities and versions against an advisory database. If it cannot establish an identity, it cannot match, and the safe-by-default behaviour is to report nothing. Zero findings therefore has three very different meanings: the components were matched and are not affected, the components could not be matched, or the components were never represented in the document.

Before you trust a zero, you need to know which of those happened. That requires looking at what the SBOM actually declares for each component, not at the scanner's summary line.

The eight causes we see most often

1. No package identifier. A component with only a name cannot be mapped to a package ecosystem, so it is skipped.
2. A version that is not an exact release: a range, a Git commit hash, a build date, “unknown” or an empty string.
3. An identifier that points at the wrong ecosystem. A Yocto recipe exposed as pkg:generic/debian-style metadata does not resolve to the distro's advisory source.
4. Vendored or renamed code. A patched copy of mbedtls compiled into a vendor blob no longer matches the upstream package.
5. Missing nested components. Only top-level dependencies are listed, so statically linked libraries inside them never appear.
6. Components that are genuinely not affected. This is the good case: matched, version compared, no advisory applies.
7. A real advisory coverage gap. Firmware vendors, RTOS components and commercial blobs are often outside open-source advisory feeds entirely.
8. Duplicate or ambiguous identities. Two components claim the same identity, so the match is discarded as ambiguous.

A five-minute diagnosis

1. Validate the document against the official schema first. A malformed file can be partially parsed and silently produce an empty component list.
2. Count the components and confirm the number is plausible for the build. A 40 MB firmware image with six components is under-declared.
3. List every component that has no purl and no CPE. Those are structurally unmatchable.
4. List every component whose version is missing, a placeholder, or not an exact release.
5. Pick two components you know are in the build and trace them by hand to the advisory database to confirm the matcher works at all.

The SBOM Validator does exactly these five checks locally: schema status, component counts split into top-level and nested, dependency-reference integrity, and a per-component reason for every component that is not query-ready.

Fix the data, then re-run

• Generate identifiers at build time from the package manager or recipe metadata, not in a spreadsheet afterwards.
• Replace descriptive versions (“latest”, “unknown”) with the exact upstream release the code came from, even if the vendor applied patches.
• Declare nested and statically linked components, with the parent relationship if you can.
• For vendor blobs, record the vendor, the module name, the exact firmware version and the hash — and accept that they may remain outside open-source advisory coverage.
• Re-validate until the “cannot be matched” list is either empty or explained.

What a genuine zero proves — and what it does not

Even a fully matched, fully declared SBOM with zero findings only tells you that no published advisory matched those identities on the day of the query. It says nothing about unpublished issues, configuration errors, exploitability in your device, or advisories published tomorrow.

That is why a one-off scan is a snapshot and why CRA obligations are about handling vulnerabilities throughout the support period, not about producing an empty report once.

Scope and limits

• This guide describes how SBOM matching fails; it does not identify vulnerabilities in your firmware.
• EmbedHarbor's public tools validate documents and identities. They do not run a vulnerability scan.

Sources

• NTIA — Minimum Elements for a Software Bill of Materials
• Package URL (purl) specification
• OSV — Open Source Vulnerabilities
• OSV schema
• CISA — Software Bill of Materials