Supporting buildkit's SBOMs / attestations

[imjasonh]

Question

Docker's buildkit and buildx can produce SBOMs and Provenance attestations when it builds an image using a Dockerfile (that's good!). They emit this information in a format that's different from cosign's format, described here: https://github.com/moby/buildkit/tree/master/docs/attestations

TL;DR: attestations are included in an image index manifest alongside the image(s) that are built, with the descriptor having a platform of unknown and annotations describing the image they're referring to, and how. These descriptors point to an OCI image manifest with layers pointing to blobs (SBOM example, more examples).

This means that attestations can't be attached to existing images in this format without modifying the digest of the manifest, and attestations aren't signed as described in those links above. Signing might be coming in a future release, I have no idea.

I don't think cosign or related tooling should produce attestations in this way, but maybe it'd be worth teaching cosign and policy-controller, etc., how to discover these attestations, and make decisions based on them, in addition to understanding cosign's externally-attached signed attestations.

[developer-guy]

I just wanted to include materials that might help us:

• https://felipecruz.es/buildkit-supply-chain-features/
• https://www.docker.com/blog/highlights-buildkit-v0-11-release/
• https://devstyler.io/blog/2023/01/31/docker-buildkit-adds-support-for-supply-chain-security-practices/
• https://docs.docker.com/build/attestations/sbom/
• https://www.docker.com/blog/generate-sboms-with-buildkit/

[dlorenc]

Question

Docker's buildkit and buildx can produce SBOMs and Provenance attestations when it builds an image using a Dockerfile (that's good!). They emit this information in a format that's different from cosign's format, described here: https://github.com/moby/buildkit/tree/master/docs/attestations

TL;DR: attestations are included in an image index manifest alongside the image(s) that are built, with the descriptor having a platform of unknown and annotations describing the image they're referring to, and how. These descriptors point to an OCI image manifest with layers pointing to blobs (SBOM example, more examples).

This means that attestations can't be attached to existing images in this format without modifying the digest of the manifest, and attestations aren't signed as described in those links above. Signing might be coming in a future release, I have no idea.

I don't think cosign or related tooling should produce attestations in this way, but maybe it'd be worth teaching cosign and policy-controller, etc., how to discover these attestations, and make decisions based on them, in addition to understanding cosign's externally-attached signed attestations.

Note that they're not signed, so we'll have to be careful about the UX on these. I agree we should support metadata in policy-controller or something, but we'll have to be clear on the difference between signed and unsigned data.

[amdawson]

related: https://github.com/sigstore/policy-controller/issues/552

[stefanprodan]

For Flux we publish SBOMs for our multi-arch images using Docker GitHub Action and we sign the multi-arch images with Cosign. I've tried downloading the SBOM with cosign but this fails like so:

$ cosign download sbom --platform=linux/amd64 ghcr.io/fluxcd/source-controller:v0.34.0

This multiarch image does not have an SBOM attached at the index level.
Try using --platform with one of the following architectures:
linux/amd64, linux/arm/v7, linux/arm64, unknown/unknown, unknown/unknown, unknown/unknown

Error: no SBOM found attached to image index
main.go:62: error during command execution: no SBOM found attached to image index

@dlorenc Is there a plan to make cosign download sbom compatible with Docker SBOM layers?

[imjasonh]

@dlorenc Is there a plan to make cosign download sbom compatible with Docker SBOM layers?

I believe this issue is the closest we have to a "plan", at least it's where we're discussing whether and how to support it.

I think Dan's point about the unsigned-by-default nature of Docker SBOMs is a good one, we don't want folks to be too confident in the SBOM if it's unsigned (same with cosign-attached unsigned SBOMs, FWIW). But if the index containing the SBOM is signed, then IMO we should trust it the same as a signed SBOM attestation produced by cosign.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.

[nettrino]

Is there an alternative option for downloading sboms from ghcr or equivalent?

[scott-hpe]

I was experementing with docker buildkit in GHA and ran into this issue where I could not use cosign to download the unsigned SBOM created by docker buildkit. We are currently experementing with multi-platform build images and looking for the most effecent way in GHA to handle the build to include sbom generation and signing.