The Yocto Project generates an SPDX software bill of materials for images by default, through the create-spdx class. After a normal image build you will find an IMAGE-MACHINE.spdx.json file in the deploy directory. A handful of SPDX variables control detail such as sources, suppliers and kernel configuration.
On by default
Yocto's documentation says the SBOM describes the components in an image, their licenses, dependencies, sources, applied changes and known vulnerabilities that were fixed. Generation is on by default because the create-spdx class is inherited through INHERIT_DISTRO. You can turn it off by removing it, but for most teams the better move is to keep it and decide what to record.
Where to find it
Build an image and look under tmp/deploy/images for your machine name. The image SBOM is a file called IMAGE-MACHINE.spdx.json. You can also build a recipe only SBOM with the create_recipe_sbom task, and recipe SBOMs are included in the image SBOM for recipes used in that image.
Settings worth knowing
Per the Yocto manual, the main variables are:
- SPDX_PRETTY formats the JSON so people can read it.
- SPDX_INCLUDE_SOURCES and SPDX_INCLUDE_COMPILED_SOURCES add source file detail.
- SPDX_INCLUDE_KERNEL_CONFIG exports the kernel CONFIG parameters.
- SPDX_INCLUDE_PACKAGECONFIG records which PACKAGECONFIG features were enabled.
- SPDX_FILE_EXCLUDE_PATTERNS drops files using regular expressions.
- SPDX_IMAGE_SUPPLIER, SPDX_SDK_SUPPLIER and SPDX_PACKAGE_SUPPLIER attach supplier information.
- Build traceability variables record which agent ran the build and for whom.
Language ecosystem classes such as cargo_common, go-mod, pypi and npm populate package URLs, which helps tools match components to advisories.
Why the kernel and PACKAGECONFIG items matter
A vulnerability often depends on a configuration. A kernel driver that is not built cannot be exploited, and a library built without a feature may not be exposed. Recording the configuration turns an SBOM from a list of names into evidence you can use when triaging.
A review checklist
- Confirm the SBOM is produced in the same pipeline run as the release image, not rebuilt later.
- Fill in supplier fields so a recipient knows who to ask.
- Check that proprietary binaries and vendor blobs appear. Anything added outside recipes may be missing.
- Store the file with the image and keep both for the support life.
- Scan it. The SBOM lists vulnerabilities that were fixed, not the ones that affect you today.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how supplier and version data make a component easy to match.
Quick check
Do I need to switch SBOM generation on in Yocto?
No. Yocto's documentation says it is on by default through INHERIT_DISTRO.
Where is the image SBOM written?
As IMAGE-MACHINE.spdx.json under tmp/deploy/images for the machine, inside the build directory.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning, policies and gates, and compliance evidence automation. Feed it the SBOMs and manifests your build produces and use gates to hold a release that fails your rules. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
