Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates the Docker image publishing workflow to attach BuildKit provenance and SBOM attestations to the pushed GHCR image, enabling downstream consumers to inspect supply-chain metadata directly from the image manifest.
Changes:
- Enable maximum-detail provenance attestation on published images (
provenance: mode=max). - Enable SBOM attestation generation and attachment (
sbom: true).
Tip
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Correction — I got a fact wrong in this PR, and I would rather flag it myself than let it sit. I wrote that the pushed manifest "carries no provenance or SBOM attestation". That is half wrong, and the wrong half matters. Provenance is already there. For public repositories, The SBOM is genuinely new. That part stands — the same page says "SBOM attestations aren't automatically added to the image", and I also wrote in the caveats that So the honest description of this PR is: it adds an SBOM attestation, and pins the provenance mode explicitly instead of relying on the default. Both are still defensible — an explicit line means the behaviour will not change quietly if the default ever does — but it is a smaller change than my description implied, and you should judge it on that basis rather than on what I originally wrote. Happy to retitle and rewrite the description accordingly, or to close this if the SBOM alone is not worth the diff to you. Either is fine — just say which and I will act on it. Apologies for the inaccuracy. It was caught by a maintainer reviewing the same change on another project, and they were right to. |
Hi, and thanks for Kamal.
.github/workflows/docker-publish.ymlpublishes the image, but the pushed manifest carries no provenance or SBOM attestation. Someone pulling it cannot check that it was built by this workflow, from this repository, at that tag.Kamal is in the deployment path rather than beside it — people run it with SSH access to their servers and registry credentials in hand, to put their own applications into production. That is a lot of authority for one container, and there is currently nothing attached to the image that an operator could check before granting it.
The change is two lines on the build step:
BuildKit attaches both to the image manifest, so they travel with the image. No permissions change is needed — nothing has to gain
id-token.There is a pleasing symmetry to it as well: Kamal's whole job is getting a known image onto a server, and this makes Kamal's own image one that can be checked the same way.
Two caveats:
mode=maxrecords build arguments (provenance: truegives a smaller record if any have ever been sensitive), and attestations add an extra manifest to the index, which the registry supports.No SLSA level claimed.
Disclosure: I used AI assistance to help spot this and prepare the change, and I read the workflow myself.