How to attest SBOM and provenance

[mu88]

Hey @baronfel,

I'm using the .NET SDK Container Building Tools to publish my multi-manifest / multi-RID images (e.g. this one).

Now I'd like to attest SBOM and build provenance, but I've no clue how to do that 🤔 I assume that this cannot be done via dotnet publish. But what needs to be done to make this work? I found this in the GitHub docs... in my case, would the GitHub Actions workflow have to look like this?

- name: Build and publish container images
  run: |
    dotnet publish ThisIsYourLife/ThisIsYourLife.csproj 
      /t:PublishContainer \
      /p:ContainerImageTags=\"dev-chiseled\" \
      /p:ContainerBaseImage=\"mcr.microsoft.com/dotnet/aspnet:9.0.10-noble-chiseled\" \
      /p:ContainerRegistry=ghcr.io

- name: Generate artifact attestation
  uses: actions/attest-build-provenance@v3
  with:
    subject-name: ghcr.io/mu88/thisisyourlife
    subject-digest: <Which hash to use?>
    push-to-registry: true

From the docs, I get the impression that the attestation should happen before the container image gets pushed. However, if this is the case, can it still work, considering that the .NET SDK Container Building Tools implicitly push the multi-manifest image?

Furthermore, which hash has to be used for subject-digest - the one of the multi-manifest image, i.e pointing to ghcr.io/mu88/thisisyourlife:dev-chiseled? Or do I have to attest build provenance in this case for the platform-specific images, i.e. ghcr.io/mu88/thisisyourlife:dev-chiseled-linux-arm64 and ghcr.io/mu88/thisisyourlife:dev-chiseled-linux-x64?

More or less the same applies to attesting the SBOM.

As always, thank you for your help 🙏🏻

[baronfel]

The docs I've found (https://github.com/actions/attest-build-provenance?tab=readme-ov-file#container-image) show pushing attestations after the image exists in the destionation registry, which is what I would expect.

This post shows the author submitting separate attestations for each architecture-specific image - though I'd also expect them to do attestation for the multi-arch manifest at the end and they don't.

So I think overall you'd need to have the digests for each of the arch-specific images and the multi-arch inded, and then create attestations for each of those. To get those we do return an MSBuild Item called GeneratedContainer that you could read via --getItem - eg: --getItem:GeneratedContainer and that could be used to get your digests.

[mu88]

If you tell me how to do so, I can give it a try.

Furthermore, do you have a workaround for addressing this issue if it's a bug?

[baronfel]

You can get a binlog by adding -bl to your command. If the problem is what I suspect there won't be a realistic user-level workaround.

[baronfel]

I did this just now and was able to retrieve both the arch-specific containers and the image index:

> dotnet publish -t PublishContainer -bl --getItem:GeneratedContainer --getProperty:GeneratedImageIndex >> containers.json

containers.json

The binlog verifies what I mostly expected to see here - I can grab the ManifestDigest properties off of each of the per-arch containers, and the GeneratedImageIndex property is itself a JSON object. However the index doesn't have the digest that you would need to reference it...

[mu88]

Please see the attached artifact.zip - it contains the output generated by the following two workflows:

• RaspiFanController/.github/workflows/CI_CD.yml
• github-actions/.github/workflows/ci-cd.yml

[mu88]

Okay, I've got a working prototype (see here). However, it requires quite a lot of surrounding code to make it work 😵‍💫

What could be done better by the .NET SDK Container Building Tools:

• When building/publishing a multi-platform image, only the platform-specific digests are returned when using --getItem:GeneratedContainer --getProperty:GeneratedImageIndex, but the multi-platform digest is missing. If the SDK would provide this digest as well, a lot of my custom code would vanish.
• When using --getItem:GeneratedContainer --getProperty:GeneratedImageIndex, the generated output is a broken JSON - the " characters are escaped as \u0022. Therefore, the PowerShell cmdlet ConvertFrom-JSON cannot be used without doing some ugly string formatting.
• It would be helpful if the output of --getItem:GeneratedContainer --getProperty:GeneratedImageIndex would provide the ability to see the tag and digest.

Long story short, the following would be very helpful:

{
  "Properties": {
    "GeneratedImageIndex": {
      "manifests": [
        {
          "digest": "sha256:f0241f6a460d1a09d965b5900c64e102b2834c0caaec11862339a8302bff3e28",
          "tag-THIS-WOULD-BE-NEW": "dev-chiseled-linux-amd64",
          "fullImageRef-THIS-WOULD-BE-NEW": "ghcr.io/mu88/raspifancontroller:dev-chiseled-linux-amd64",
          "platform": {
            "architecture": "amd64",
            "os": "linux"
          }
        },
        {
          "digest": "sha256:68faf0830bae4fdefb6c862112016057de2d11d44d4e63b1c50199e623002eac",
          "tag-THIS-WOULD-BE-NEW": "dev-chiseled-linux-arm64",
          "fullImageRef-THIS-WOULD-BE-NEW": "ghcr.io/mu88/raspifancontroller:dev-chiseled-linux-arm64",
          "platform": {
            "architecture": "arm64",
            "os": "linux"
          }
        }
      ]
    }
  },
  "Items": {
    "GeneratedContainer": [
      {
        "name": "dev-chiseled-linux-amd64",
        "fullImageRef": "ghcr.io/mu88/raspifancontroller:dev-chiseled-linux-amd64",
        "imageDigest": "sha256:f0241f6a460d1a09d965b5900c64e102b2834c0caaec11862339a8302bff3e28"
      },
      {
        "name": "dev-chiseled-linux-arm64",
        "fullImageRef": "ghcr.io/mu88/raspifancontroller:dev-chiseled-linux-arm64",
        "imageDigest": "sha256:68faf0830bae4fdefb6c862112016057de2d11d44d4e63b1c50199e623002eac"
      },
      {
        "name": "dev-chiseled",
        "fullImageRef": "ghcr.io/mu88/raspifancontroller:dev-chiseled",
        "imageDigest": "sha256:5eec17bfffabeb60b28d345e48386b1747c30f1ba91560bac59fb34261374793"
      }
    ]
  }
}