Goal:

• Some customers need to have an open source compliance process, e.g. to align with European Union directives. The compliance process needs the list of software installed in a system with their license. When using Image Builder to generate the OS images, having a SBOM would simplify the process.
• Ideally, the SBOM should be available in SPDX and CycloneDX formats to allow customers to use their format their tools support.

Acceptance Criteria:

• A SPDX formatted SBOM is available alongside an Image Builder generated compose
• The SBOM are available via the Image Builder API
• The SBOM are available via the Image Builder CLI
• The SBOM are available in Koji / Brew image builds
• The SBOM are available via the Image Builder Cockpit UI

Out of scope:

• CycloneDX SBOM format

Open questions:

• What should be the location of SBOM file in the built image?
  • [proguski] In regards to the SBOM location in images, I would suggest something that is easily available. I remember that some long time ago one of the scanning vendors informed me that they can't get access to the current build_info directory located in the root homedir from the user level perspective. So, it would be good to have a location that will be available without problems.
  • [mprpic] Konflux and OSBS sort of standardized on including content manifests under /root/buildinfo/content_manifests. I think since these will be actual SBOMs (license and provenance included), they could be placed under /root/buildinfo/bom/ or something like that to support different types (OBOM, SBOM, ...).

Details

Red Hat prefers SPDX SBOM format. Konflux and RHTAP is moving towards SPDX.

Implementation

We'll take "layered approach". We should generate the parts of SBOM where the relevant data are obtained or available. This means that Various IB components will generate a partial SBOM while processing an image build, with the intention to eventually combine these partial SBOMs to a single complete one.

Example:

• When the image package set is depsolved by the dnf-json component, the component should generate an SBOM that corresponds to the final package set. The caller can then use this accordingly, depending on the purpose of the package set (e.g. if it is for the buildroot, image payload, ISO tree, etc.).
• When a tool (osbuild-composer / gen-manifests / otk) generates an osbuild manifest, it can generate an SBOM which includes the information from dnf-json, and adds additional information to it, such as user customizations.
• When osbuild builds a manifest, it generates an SBOM (as part of the build) per each exported pipeline. The information added on this layer would be the build e.g. the build environment, actually enabled services in the image, etc.

Milestones

M1 - Packages (MVP)

• Extend dnf-json to return information about the depsolved package set in the SPDX SBOM format.
• Whichever tool that does the depsolving (osbuild-mpp, osbuild-composer, otk) will put that into context (probably map it to a specific osbuild pipeline).
• Composer Cloud API (used by Koji / Image Builder service) will provide a new endpoint to get SBOM with image package set information for the particular image build.
• Upload the SBOM file to Koji / Brew image build
• Out of scope:
  • Exposing the SBOM in Image Builder API
  • Exposing the SBOM in cockpit-composer UI
  • Exposing the SBOM in the Image Builder SaaS

M2 - Build environment

• Will be generated by osbuild when building a specific manifest. osbuild may need to take “package set SBOM” mapped to pipelines as an input, to be able to put them into context based on the --export parameter used to build the image.
• This should go into EBOM

M3 - Customizations

• Include user customizations applied to the image.

...