ci: attach provenance and SBOM attestations to the published image - #3920
ci: attach provenance and SBOM attestations to the published image#3920kobihikri wants to merge 1 commit into
Conversation
|
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 cAdvisor.
.github/workflows/publish-container.ymlpublishesghcr.io/google/cadvisoron every tag, 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.cAdvisor seemed a worthwhile one to raise because of where it runs: it is typically deployed as a DaemonSet with access to the container runtime socket and the host filesystem, on every node in a cluster. That is a high-trust placement, and right now the image carries nothing a cluster operator could verify 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 to GHCR. No permissions change is needed —
contents: readandpackages: writestay as they are, and nothing needsid-token. Yourmetadata-actiontag rules are untouched.Operators can then check with:
Two caveats:
mode=maxrecords the full build including build arguments (provenance: truegives a smaller record if any have ever been sensitive), and attestations add an extra manifest to the index — GHCR supports this, but it is worth knowing if a mirror or an air-gapped copy step sits in the path, which is not unusual for cluster tooling.No SLSA level claimed here; the attestation is what BuildKit produces.
Disclosure: I used AI assistance to help spot this and prepare the change, and I read the workflow myself.