Attestations for multi-platform images

[jkreileder]

What is the recommended way to attest SBOMs for multi-arch images? The documented way of generating and attesting surely doesn't work:

• First anchore/sbom-action generates an SBOM for a single platform (most likely amd64)
• Then actions/attest-sbom attaches that single-platform SBOM to the multi-platform index

Here's an example:

$ crane digest jkreileder/cf-ips-to-hcloud-fw:1.0.11
sha256:bf5a71bdd31fc00feb2a727b1a0f9442e2d93460d0d6f3e11685937714dda3e9
$ crane digest --platform linux/amd64 jkreileder/cf-ips-to-hcloud-fw:1.0.11
sha256:ed9821fe41944f3b90050accd78aa3b52256809b31cb024ffd3eff31b8718ce0
$ crane digest --platform linux/arm64 jkreileder/cf-ips-to-hcloud-fw:1.0.11
sha256:43818671e5ed3569fa86a69f1ba6f4e8b83ebe3b6f2a0909b10a9007566cab0f

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:

$ docker buildx imagetools inspect jkreileder/cf-ips-to-hcloud-fw@sha256:bf5a71bdd31fc00feb2a727b1a0f9442e2d93460d0d6f3e11685937714dda3e9 --format "{{ json .SBOM }}"
{
  "linux/amd64": {
    "SPDX": {
[...]
    }
  },
  "linux/arm64": {
    "SPDX": {
[...]
    }
  }
}

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.)

[bdehamer]

@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.

[scott-hpe]

+1 to say we were looking at the same thing. For multi-arch containers, a clean way to generate sbom, sign, attest