SBOM- Cosign spec

[RealHarshThakur]

Hey folks, it looks like there's an interoperability issue between Buildpacks and Cosign tooling. As an end user, I would like : pack sbom download and cosign download sbom to work on any OCI artifact regardless of the build tool. Cosign has a spec for what this should look like: https://github.com/sigstore/cosign/blob/main/specs/SBOM_SPEC.md Harbor is also looking to comply to cosign spec: https://github.com/goharbor/harbor/issues/16397

Currently, Buildpacks doesn't seem to attach the SBOM in the OCI image manifest. If that was done, it should make both tools interoperable and also easy to use with other libraries in the ecosystem.

[developer-guy]

There is an ongoing issue related to that topic, but this issue is more likely related to the Docker BuildKit, but anyways it might help:

https://github.com/sigstore/cosign/issues/2688#issuecomment-1422632409

[RealHarshThakur]

I've made a small go program that takes the layers directory and image to attach SBOM according to Cosign spec. It'll have to be split into lifecycle binary and imgutils package buildpack uses. I'm not quite sure how this would be structured in imgutils as there could be other media types(attestations, etc), so I guess a new generic method might be needed in there: https://github.com/buildpacks/imgutil/blob/main/image.go#L36

[AidanDelaney]

Also of interest is how cosign integration is achieved in kpack.

[natalieparellano]

@RealHarshThakur this is awesome to see!

Summarizing for my own understanding (and to help others): the program takes an image reference and a directory, adding the individual json files within the directory (if they have the suffix spdx.json, cdx.json, or syft.json) as individual layers within the image manifest, giving each layer the appropriate media type. In theory, the lifecycle could invoke this logic at the point of saving the application image. This work could also be done by some other binary (e.g., the "signer") but that may have poorer performance as the SBOM layer/directory would first need to be fetched from the registry so that the files could be re-attached (the lifecycle already has the files available to it in the build container). Potentially, the lifecycle could also add a "scope" to an SBOM layer to point back to the image layer that is described, but this would introduce additional complexity.

Regarding the introduction of this logic to imgutil, my recommendation would be to keep the imgutil interface as logic-less as possible (something like AddLayerWithMediaType) and leave it up to the lifecycle to call this method for each SBOM file being added.

@RealHarshThakur would you be up for opening an RFC about this? I would really love to see this move forward, so if there is any help that I could provide please let me know.

[RealHarshThakur]

Thanks Natalie.

Potentially, the lifecycle could also add a "scope" to an SBOM layer to point back to the image layer that is described, but this would introduce additional complexity.

I was thinking about this, we'll need to somehow map the sha hash of the layer to the sbom file/sbom sub-directory. Are SHA hashes stored somewhere in the layers directory/can they be computed on the fly by lifecycle? In general, my preference is not to delegate this to builder images but to have lifecycle do the heavy lifting unless there's no other way.

would you be up for opening an RFC about this?

Yep, I'll draft it up