Currently, the SBOMs are generated at the lowest level of the stack, where all metadata about RPM packages is available. Although this seemed to be a reasonable approach at the time of the MVP, it turned out to be impractical if we needed to combine multiple “layers” of an image into a single SBOM document.

Therefore, the proposal is to make the osbuild/images library the central point that gathers all the metadata about any content that goes into an image. With this knowledge and all the information about image composition, it is the ideal and natural place to generate the SBOM document.

Inside osbuild/images library, the implementation should be hooked onto the osbuild manifest generation process, which leverages all the content metadata to generate the manifest. In principle, the SBOM is tightly coupled with the osbuild manifest and describes the artifact that will be produced by osbuild when building the manifest.

We should start with RPM packages, which are installed in the image. However, by moving the SBOM generation to osbuild/images, we’ll be prepared to easily extend the implementation to cover any other content that ends up in the image, such as embedded container images and any custom files.

SBOMs should be internally represented in a standard-agnostic manner, providing us with the flexibility to support any format that may be required in the future. The proposal is to use https://github.com/protobom/protobom Golang library as the SBOM standard-agnostic format to represent and construct SBOMs internally. OpenSSF backs the project. The project supports serializing SBOMs to SPDX 2.3, which is the bare minimum that we need. There are also plans to extend its supported output formats, making it a good choice in case we need to support more than just SPDX or multiple versions of it.

Implementation outline

• Consolidate data structures representing RPM package metadata in osbuild/images to be complete and contain all information exposed by DNF.
• Extend osbuild-depsolve-dnf to return the full RPM package metadata for any response that describes RPM packages (depsolve, search, dump).
• (optional) Implement the building of the pipeline dependency graph for a given image type manifest in osbuild/images, and tie it to any content landing in the pipeline (packages, container images, etc.). This would then be used to determine which pipelines make up the image, going backward from the export pipeline, and to identify what needs to be described in the SBOM. This would also allow us to export different pipelines from the manifest and generate an SBOM specific to the exported pipelines.
• Implement SBOM generation from the content metadata in osbuild/images, starting with RPM packages.
• Replace the SBOMs generated by osbuild-depsolve-dnf with the SBOMs generated internally by osbuild/images. To start, we can continue generating SBOMs per pipeline and rework them in the next phase into a single, comprehensive SBOM.

Acceptance Criteria

• SBOMs generated by users of the osbuild/images library (ibcli, osbuild-composer) are generated by the library from the content metadata as part of the image manifest generation.
• SBOMs are no longer requested from osbuild-depsolve-dnf for depsolved transactions.
• osbuild-depsolve-dnf returns all available RPM metadata consistently for all operations.
• SBOM experience when generated by osbuild/images is the same as now, meaning that there is a separate SBOM document per each manifest pipeline that installs RPMs.

Out of scope

• Generating a single SBOM for an image with multiple pipelines that install RPMs (i.e. the installer ISO images).
• Generating SBOM with a single entry point "meta" package representing the image as such.