Yocto and Buildroot SBOMs vs firmware image scanning: when do you need both?

An SBOM is only as good as the place it was recorded. NTIA's Minimum Elements for a Software Bill of Materials names three points where component data can be collected: "from the software source, at build time, or after build through a binary analysis tool", and warns that "the SBOM may have some differences depending on when and where the data was created". The same report asks SBOM authors to state "known unknowns" explicitly, so a consumer can tell a component with no further dependencies from one whose dependencies were simply not enumerated. The baseline fields themselves (supplier, component name, version, unique identifiers, dependency relationship, author, timestamp) are covered in our SBOM minimum elements guide.

For embedded Linux this choice is concrete. The build system sees every recipe, its upstream version and every patch applied to it, which a binary scanner can only infer. The finished image contains every file that actually ships, including files that never passed through a recipe. Each view has blind spots the other one covers.

The Yocto Project Development Tasks Manual states that the OpenEmbedded build system generates an SBOM "by default (by inheriting the create-spdx class in INHERIT_DISTRO)", describing "all the components you used, their licenses, their dependencies, their sources, the changes that were applied to them and the known vulnerabilities that were fixed". Building an image writes IMAGE-MACHINE.spdx.json to tmp/deploy/images/MACHINE/, and bitbake <recipe> -c create_recipe_sbom produces one from recipe metadata alone. The output is SPDX, the format the SPDX project describes as "recognized as the international open standard for security, license compliance, and other software supply chain artifacts as ISO/IEC 5962:2021"; on the Scarthgap 5.0 LTS release SPDX 3.0 output is off by default and is switched on by replacing create-spdx with create-spdx-3.0 in INHERIT_DISTRO. Our SPDX 3.0 specification guide covers what changed in that format version.

The defaults are a starting point. Variables add the detail that matters for security review:

For vulnerabilities, the Scarthgap Checking for Vulnerabilities chapter enables the cve-check class with INHERIT += "cve-check", which maps "each compiled software component recipe name and version information to the CVE database" and writes per-recipe reports to tmp/deploy/cve. The current Yocto Project Security Manual describes its successor, sbom-cve-check, enabled with the core/yocto/sbom-cve-check configuration fragment, which writes an image-level report plus an SPDX file enriched with the same CVE data. Both give every matched CVE one of three statuses: Patched, Unpatched or Ignored. Two details decide whether those statuses are right. A backported fix counts as Patched only when its patch header carries a CVE: tag. When a recipe name does not match the CVE database's product name, CVE_PRODUCT (for example "flex_project:flex westes:flex") corrects the mapping in both directions.

The Buildroot user manual splits the job across several make targets rather than one SBOM class:

• make legal-info collects licence-compliance material under legal-info/: the Buildroot configuration, package sources, the patches that were applied, licence texts, and "a manifest file (one for host and one for target packages) listing the configured packages, their version, license and related information". Items Buildroot cannot determine are marked "unknown".
• make show-info prints a JSON description of the enabled packages "together with their dependencies, licenses and other metadata"; piping it into utils/generate-cyclonedx produces a CycloneDX SBOM. Our CycloneDX vs SPDX guide compares the two formats.
• make pkg-stats produces HTML and JSON output including "whether known CVEs (security vulnerabilities) affect the packages in your current configuration" and whether a newer upstream version exists.

Per-package metadata drives the matching. LIBFOO_CPE_ID_* variables set each package's CPE identifier, with the vendor defaulting to <pkgname>_project. LIBFOO_IGNORE_CVES records CVEs that a patch fixes or that do not apply to Buildroot's build of the package, and the manual requires a Makefile comment explaining each one. The manual is also direct about the limits of legal-info: its output "is based on declarative statements in each of the packages recipes", and those statements may not be "fully accurate nor exhaustive", so it must be checked before you rely on it.

Both build systems describe what their recipes declare. Anything that reaches the image without a recipe, or with wrong recipe metadata, is invisible to them:

The reverse is also true. A binary scan cannot see a backported patch the way the build system does: a scanner that reads OpenSSL's version string may flag CVEs your recipe already fixed with a CVE:-tagged patch. That is why the build SBOM remains the primary record, and why the build system's Patched and Ignored statuses (with the reason recorded) are the evidence that closes such a finding. Publishing those decisions as VEX is covered in our CSAF and VEX for device makers guide.

You need both whenever the image contains anything not built from your own layers or packages, which for most commercial embedded Linux products means always: board support packages, vendor blobs and post-build steps are the norm. A workable release step:

1. Generate the build SBOM and CVE report on every release build (create-spdx plus cve-check or sbom-cve-check on Yocto; show-info with generate-cyclonedx, pkg-stats and legal-info on Buildroot) and keep them with the release artefacts.
2. Scan the exact image file you flash or ship, not an intermediate rootfs, and produce an image-derived SBOM.
3. Diff the two by component name and version. Anything in the image scan but missing from the build SBOM is a component to add, with its supplier. Anything with different versions needs a decision: a backport, a misdeclared version or a stale package.
4. Prioritise the remaining open CVEs by exploitation evidence rather than CVSS alone, as our KEV and EPSS prioritisation guide describes, and record each "not affected" decision with its reason.

Our firmware SBOM guide covers the image side of this process when no build-system SBOM exists at all, such as for third-party modules you integrate but do not build.

SoftWSP works on the finished image, the second half of the comparison above. The pipeline unpacks a firmware image, identifies the software components and versions present in its binaries, and matches each component version against public CVE records, CISA's Known Exploited Vulnerabilities catalog and FIRST EPSS scores. The matching and scoring are deterministic code. AI's role is narration: it writes the plain-language summary of which components were found, which CVEs match and which are KEV-listed or high-EPSS, with each statement citing the component, version and record behind it. An engineer reviews every finding before the report ships. Code scores, AI narrates.

The service report carries the image-derived SBOM, one per firmware version, which sits beside your Yocto or Buildroot SBOM. Our free SBOM diff tool runs in your browser and lists added, removed, version-changed and licence-changed components between any two CycloneDX or SPDX 2.x JSON SBOMs, such as two consecutive release builds. Deciding why a difference exists, such as whether a version mismatch is a backported fix your cve-check report already marks Patched, stays with your engineers. SoftWSP does not read your build tree, layers or recipes.

This guide draws on the Yocto Project Development Tasks Manual and Security Manual (current and Scarthgap 5.0), the Buildroot user manual, NTIA's Minimum Elements for an SBOM and the SPDX project's overview, read directly 2026-11-10.