feat: add supply chain attestations to Docker image builds

[stack72]

Summary

• Add SLSA provenance (mode=max) and SBOM generation to both amd64 and arm64 Docker image builds
• Add id-token: write permission to the docker job for OIDC-signed provenance

Impact

Docker Hub will now receive full supply chain attestations alongside each image push:

• Provenance — cryptographically signed record of what was built, by which workflow, from which commit. Uses GitHub's OIDC token via Sigstore/Fulcio for signing.
• SBOM — SPDX software bill of materials generated by BuildKit's built-in scanner

This improves the Docker Hub security score and gives consumers verifiable proof of image origin.

Why this is safe

The id-token: write permission only allows the job to request a short-lived OIDC token from GitHub's token endpoint. It cannot access repo contents, secrets, or the GitHub API. The token is scoped to the workflow run and expires immediately after.

Test plan

• Verify CI passes
• After next release, confirm attestations are visible:

  docker buildx imagetools inspect systeminit/swamp:<tag> --format '{{json .Provenance}}'
  docker buildx imagetools inspect systeminit/swamp:<tag> --format '{{json .SBOM}}'
  

🤖 Generated with Claude Code

[github-actions]

CI Security Review

Critical / High

None.

Medium

1. .github/workflows/release.yml — workflow-level permissions: contents: write: Permissions are set at the workflow level (line 13-14), meaning all jobs inherit contents: write, including the docker job which only needs contents: read. The docker job correctly overrides this at the job level (line 173-175), so this is not exploitable, but it would be cleaner to remove the workflow-level permissions and set them per-job. This is a pre-existing issue, not introduced by this PR.

2. Third-party actions pinned by tag, not SHA: docker/build-push-action@v6, docker/setup-qemu-action@v3, docker/setup-buildx-action@v3, docker/login-action@v3, and peter-evans/repository-dispatch@v3 are pinned to major version tags rather than commit SHAs. A compromised tag could inject malicious code into this privileged release workflow. This is pre-existing and not introduced by this PR.

Low

None.

Verdict

PASS — The changes add id-token: write permission to the docker job (needed for SLSA provenance attestations) and enable provenance: mode=max and sbom: true on both Docker build-push steps. These are security improvements — they add supply chain attestation (SLSA provenance) and software bill of materials (SBOM) to the published container images. The id-token: write permission is correctly scoped at the job level and is required for the sigstore-based provenance generation used by docker/build-push-action. No new vulnerabilities introduced.

[github-actions]

Code Review

Blocking Issues

None.

Suggestions

1. Attestation propagation to multi-arch manifest: The docker buildx imagetools create step (line 236) should correctly propagate provenance and SBOM attestations from the per-platform images into the merged manifest. This is the expected behavior with build-push-action@v6, but worth verifying after the first release by running the imagetools inspect commands from the test plan against both the platform-specific tags and the multi-arch tag.

Overall: Clean, minimal change. The id-token: write scope is appropriate and safe, and adding provenance + SBOM to both platform builds is the correct approach.