[Umbrella] Bill of Materials

[puerco]

We intend to ensure the quality and integrity of the artifacts produced on each release cut by adding a Bill of Materials (BOM). The BOM will be published in SPDX and will include integrity and licensing information for the artifacts we produce. Work on this area will lead to close other outstanding issues (linked here).

Following our road-mapping session, this umbrella issue will track the development to create the BOM.

Make krel aware of binary artifacts expected from the release process:

Note: These items are postponed as we delayed the supported platforms effort to 1.23+

• Read the data from the proposed (Add machine readable description of platforms #1836) machine-readable platform map
• Bootstrap the Release Process state object with files expected as output, crossing the platform data and options specified in the run.

Verify/process binary artifacts as the release process advances from stage to stage

• Verify binaries to ensure the platform is correct (Add verification logic to ensure all Golang binaries in core images are of the same arch #1521 Release process artifact verification #2160 )
  This step involves:
  • Creating a new API in our tools to check the binaries (@puerco Binary package: Base module for binary analysis #1856)
  • Integrating it into the release process to check compiled artifacts (Release process artifact verification #2160)
• Verify tagging in binaries (issue Add a check to ensure release binaries have the correct tag versions before publishing #1898) (Release process artifact verification #2160)
  We need to ensure that binaries are correctly tagged with the corresponding semver tag and commit sha

Write SPDX manifest(s). Output should include data about:

• Naked binaries (Generate the first SBOM protoype from the Kubernetes release process #2095)
• Images (Provide links to k8s control plane images #1384) (Generate the first SBOM protoype from the Kubernetes release process #2095)
• Third-party licences (Improve license transparency for vendor/ in Kubernetes kubernetes#94976) .
  To accomplish this one we will need to:
  • Write or use a license parsing tool to obtain licenses of external modules. (Add k8s.io/release/pkg/license package #1874 @puerco)
  • Integrate the scanner into the release process scanning the vendor/ directory in k/k to get the licenses that will be added to the BOM Scan all dependencies licensing information and include them in the SBOM (Generate the first SBOM protoype from the Kubernetes release process #2095)

Publish the SPDX manifests with the other release artifacts:

• Generate the BOM in one or more formats supported by SPDX: tag, RDF, etc. (Generate the first SBOM protoype from the Kubernetes release process #2095)
• Write them to a subdirectory in the release bucket (Generate the first SBOM protoype from the Kubernetes release process #2095)
• Upload manifests as assets in the GitHub release page Note: In later discussions we chose to publish the documents only via https for now and not relay on the GH release page.
• Publish the SBOM documents via sbom.k8s.io (SBOM domain redirects: nginx + DNS config k8s.io#2447)

Make our tools available community-wide

• Build a general-purpose tool to generate SPDX compliant SBOMs (bom: A utility to generate SPDX compliant Bills of Materials #2066)
• Support defining complex SBOM compositions from a yaml file (Fixes to SBOM libraries #2096)
• Add bom utility documentation (Full set of bom READMEs and documentation #2109)
• Write an in-depth guide to generating SPDX bill of materials (Full set of bom READMEs and documentation #2109)

/cc @hasheddan @xmudrii @markyjackson-taulia

[nishakm]

cc @rnjudge and @kestewart for Tern

[tsteenbe]

@puerco If you need a tool to generate SPDX for Go and other languages, have a look at OSS Review Toolkit. I am both ORT and SPDX maintainer, happy to answer any questions you may have.

[puerco]

Thank you @tsteenbe I certainly will take a look at it :)

[lasomethingsomething]

/area release-eng

[justaugustus]

Connecting some threads based on an OSS supply chain convo I had earlier in the week with folks across VMware, Red Hat, and Google (@ncdc, @dlorenc, @wattsteve, @lukehinds, @kimsterv, @jonjohnsonjr to name a few):

• https://github.com/opencontainers/image-spec/blob/master/spec.md
• https://github.com/opencontainers/distribution-spec/blob/master/spec.md
• OCI artifact manifest, Phase 1-Reference Types opencontainers/artifacts#29
• [Presentation] Rekor tamper-resist ledgar cncf/tag-security#467 (comment)
• https://rekor.dev/
• https://rekor.dev/docs/plugable_types/

@saschagrunert @hasheddan @puerco -- Let's please leverage Rekor here as we build this out.

Of course, there's more to consider and supply chain concerns will be core to everything we do in RelEng, but the bill of materials is a great starting point.

cc: @kubernetes/sig-security-leads

Project Rekor xref: sigstore/rekor#156, sigstore/rekor#144