SBOM

Every image build produces a Software Bill of Materials (SBOM) describing the components that end up on the target, so that the BSP can be checked against known vulnerabilities.

Two formats are generated side by side:

• CycloneDX — produced by the cyclonedx-export class from the meta-cyclonedx layer. It comes with a companion VEX document holding the vulnerability analysis.
• SPDX — produced by Yocto's own create-spdx class, which is part of the default distro inherits. It is shipped in the BSP release archive.

Generated Documents

The CycloneDX export writes two documents per image into the deploy directory next to the image files:

File	Content
<image>.cyclonedx.bom.json	the SBOM, one component per package
<image>.cyclonedx.vex.json	the VEX, the vulnerability analysis for those components

Both are also copied into the per-platform firmware archive (firmware-ked-<platform>_<version>.zip) of a release.

Configuration

The policy lives in layers/meta-ked/conf/distro/ked.conf:

CYCLONEDX_SPEC_VERSION ?= "1.7"
CYCLONEDX_RUNTIME_PACKAGES_ONLY ?= "1"
CYCLONEDX_IMAGE_VERSION ?= "${DISTRO_VERSION}"
CYCLONEDX_EXTRA_RUNTIME_RECIPES ?= "virtual/bootloader"

CYCLONEDX_RUNTIME_PACKAGES_ONLY restricts the SBOM to what is actually installed on the target, instead of listing every recipe that took part in the build. The boot chain is written to the boot media rather than installed as a package, so it is invisible to such an SBOM and has to be listed explicitly in CYCLONEDX_EXTRA_RUNTIME_RECIPES.

Adding a machine

Listing a recipe that the machine does not build makes do_export_cyclonedx fail. The boot chain differs per SoC, so the variable is extended through machine overrides. A new SoC needs its own append.