Buildroot can produce a CycloneDX SBOM from its show-info data, and Yocto's create-spdx class writes an SPDX JSON document for the image and SDK. Both give a component list for what the build system itself built. Neither knows about files you copy in by other routes.
What the documentation says
Buildroot. The manual describes make show-info, which gives a JSON description of enabled packages with dependencies and licenses, and CycloneDX SBOM generation based on that output. It says the SBOM can be enriched with vulnerability analysis from the NVD database through a cve-check script, and that pkg-stats reports whether known CVEs affect packages in your configuration.
Yocto. The reference manual describes the create-spdx class as automatically creating SPDX SBOM documents based on image and SDK contents. It is meant to be inherited globally from a configuration file and writes a JSON file named IMAGE-MACHINE.spdx.json into the image deploy directory. Output detail is controlled with SPDX variables, including options for pretty printing and including sources.
| Point | Buildroot | Yocto |
|---|---|---|
| SBOM format described | CycloneDX | SPDX JSON |
| Starting data | show-info JSON | Image and SDK contents |
| Vulnerability view in the docs | pkg-stats and cve-check script | Not covered in the section reviewed here |
| Output location | Where you generate it | Image deploy directory |
I did not verify Yocto's own CVE tooling for this article, so check its current documentation if that matters to you.
Choosing an approach
You rarely choose the build system for the SBOM. Still, the output shapes your process.
- Match your customers. If buyers ask for SPDX or CycloneDX, confirm you can export it, or plan a conversion step.
- Automate at release. Generate the file in the same CI job that makes the image and store it with the image.
- Add what is missing. Vendor blobs, copied libraries and application code embedded in the image need manual entries.
- Validate. Spot check a few components against the real image contents.
What neither covers
An SBOM from the build system is a statement about the recipe, not a forensic inspection of the finished image. If a post-build script drops in a binary, the SBOM will not mention it unless you add it. Close that gap by listing every post-build step and what it adds.
Format conversion
If you need the other format, conversion tools exist, but a conversion can lose fields. Test with your consumers before promising it.
Where Safeguard fits
If you want an inventory your reviewers can query, Safeguard offers SBOM and dependency scanning with policies and gates on pull requests. It works from the source and manifests it supports. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Look at how the inventory presents name, version and license. Those are the same facts either format has to carry.
Click through it at your own pace, or open it full screen.
Quick check
Can I use both formats?
Yes. Some teams generate one natively and convert the other, then check what the conversion loses.
Is the SBOM complete once the build system exports it?
Only for what the build system built. Review anything added outside it.
Sources
Last reviewed: 19 October 2026.
