Add initial support for generating SPDX SBOM documents (COMPOSER-2274)

[thozza]

Depends on:

• Add initial support for generating SPDX SBOM documents (COMPOSER-2274) osbuild#1818

• Add initial support for generating SPDX SBOM documents (COMPOSER-2274) images#930

• Extend the worker Depsolve job to allow requesting an SBOM document for each transaction. The SBOM documents are returned in the DepsolveJobResult.

• CloudAPI:

  • Unconditionally request SBOM documents for every Depsolve job.
  • Add new /composes/{id}/sboms API endpoint for requesting SBOM documents for composes.
  • Extend the non-Koji and Koji compose unit tests to verify the newly added /composes/{id}/sboms API endpoint.

• There's no support for SBOMs added to Weldr API.

• Koji:

  • Extend the Koji target result to include SBOM documents uploaded to the Koji build.
  • Extend the KojiFinalize job to import all SBOM documents uploaded to the Koji build and listed in the Koji target result.
  • Extend the Koji target handling in the OSBuild job, to upload all SBOM documents, related to the OSBuild job, to the Koji build and list them in the Koji target result. Uploaded SBOM documents use the following filenames: <image_filename>.<pipeline_purpose>-<pipeline_name>.spdx.json.
  • Extend the koji.sh test case to verify the uploaded SBOM documents in Koji builds.
  • Update the tested scenarios for koji.sh. Specifically, test the main scenario on RHEL-9 and in addition, test building of RHEL-8 and RHEL-10 on RHEL-9.

Details

SBOM documents are attached to DepsolveJobResult. For each package set that was depsolved, there will be a corresponding SBOM document. DepsolveJob usually contains at least two package sets for any image type - for the at least one image pipeline and for the buildroot pipeline.

Koji composes may contain multiple image builds as part of a single compose request. Therefore the /composes/{id}/sboms endpoint returns multiple SBOM documents for each image build. The returned value may look as follows for a Koji compose that consists of two image builds:

{
	"href": "/api/image-builder-composer/v2/composes/356f4620-c03e-3830-b013-ddbfee6665aa/sboms",
	"id": "356f4620-c03e-3830-b013-ddbfee6665aa",
	"kind": "ComposeSBOMs",
	"items": [
		[
			{
				"pipeline_name": "build",
				"pipeline_purpose": "buildroot",
				"sbom": <sbom_doc>,
				"sbom_type": "spdx"
			},
			{
				"pipeline_name": "os",
				"pipeline_purpose": "image",
				"sbom": <sbom_doc>,
				"sbom_type": "spdx"
			}
		],
		[
			{
				"pipeline_name": "build",
				"pipeline_purpose": "buildroot",
				"sbom": <sbom_doc>,
				"sbom_type": "spdx"
			},
			{
				"pipeline_name": "os",
				"pipeline_purpose": "image",
				"sbom": <sbom_doc>,
				"sbom_type": "spdx"
			}
		]
	]
}

pipeline_purpose describes the purpose of a pipeline. image means that the content described in the SBOM document is installed in the actual image. buildroot means that the content described in the SBOM document was installed in the environment used to build the image. This terminology is consistent with how we name thing internally.

pipeline_name is the actual name of the osbuild pipeline, in which the described content got installed.

sbom is the actual SBOM document.

sbom_type describes the SBOM standard / type of the SBOM document. Currently, it will be always spdx.

[achilleas-k]

Great work. This is a lot.

Couple of notes and nitpicks. I think there's a bug in the sbomsFromOSBuildJob() function (noted below) but I'm not entirely sure if I'm reading it right so not Requesting changes.

[achilleas-k]

All good!

[kingsleyzissou]

Also LGTM

[schuellerf]

lgtm