Open jkreileder opened 2 months ago
@jkreileder at this point we aren't particularly opinionated about how to handle attested SBOMs. A lot of this really depends on what you want to do with the SBOM after you've generated/attested it. Is it just an artifact that you need to have to satisfy an audit requirement? Is it something that you want to be able to write policy against to gate the deployment of your application?
As you noted, the multi-arch image use case is sorta clunky to make work with the attest-sbom
action. The anchore/sbom-action
probably isn't doing what you want here, yet the buildx-generated SBOMs require a fair bit of wrangling to get them piped-in to attest-sbom
. I could imagine adding a flag to attest-sbom
which would trigger the retrieval and attestation of the buildx-generated SBOMs.
Ultimately, we'd like to put together some recommendations/recipes for how to do this but are still gathering data at this point. We'd definitely be interested to hear what your use cases are for consuming/verifying the generated SBOMs.
Luckily, the story is a bit more clear when it comes to build provenance. I think that the docker buildx-generated provenance statement is complementary to the one generated by the attest-build-provenance
action. While the buildx provenance gives you a lot of information about the docker build
steps which were executed to build the image, you don't really get any information about the GHA workflow context in which that build was done. On the other hand, the GHA provenance statement gives you a pointer to the workflow definition, the git SHA from which the build was triggered, the runner type, etc.
Together, the docker provenance and the GHA provenance give you a pretty good picture of the overall build context.
To that end, I think it's appropriate for the GHA provenance to treat the multi-arch image digest as the subject since the assertions being made apply to ALL of the images which were built in this workflow run (there's nothing in the GHA provenance statement which is specific to a particular arch build).
One nice side-effect of this approach: given that the multi-arch image contains both the images AND the buildx-generated provenance/sbom statements, the GHA provenance attestation is effectively a signature over EVERYTHING.
+1 to say we were looking at the same thing. For multi-arch containers, a clean way to generate sbom, sign, attest
What is the recommended way to attest SBOMs for multi-arch images? The documented way of generating and attesting surely doesn't work:
anchore/sbom-action
generates an SBOM for a single platform (most likely amd64)actions/attest-sbom
attaches that single-platform SBOM to the multi-platform indexHere's an example:
This was generated by https://github.com/jkreileder/cf-ips-to-hcloud-fw/blob/48ab6e2f78e92677684ca33cfd39f41971026801/.github/workflows/docker.yaml in https://github.com/jkreileder/cf-ips-to-hcloud-fw/actions/runs/9020189970.
Docker buildx itself generated two SBOMs:
The SBOM from
anchore/sbom-action
however is amd64-specific: https://github.com/jkreileder/cf-ips-to-hcloud-fw/actions/runs/9020189970/artifacts/1488347718=> The generated attestation (https://github.com/jkreileder/cf-ips-to-hcloud-fw/attestations/816931) is amd64-specific and basically useless for arm64.
How should this be handled? Extract the SBOMs from the docker build (as shown above) and pass those to
actions/attest-sbom
although it doesn't follow the expected format? Wouldn't it be better to just directly attest the already pushed SBOMs?Note that this might apply to build provenance attestations as well if those ever contain platform specific things. (Docker buildx e.g. does, so it attaches multiple provenances too. See
docker buildx imagetools inspect jkreileder/cf-ips-to-hcloud-fw@sha256:bf5a71bdd31fc00feb2a727b1a0f9442e2d93460d0d6f3e11685937714dda3e9 --format "{{ json .Provenance }}"
for example.)