ci: attach provenance and SBOM attestations to the published image

[kobihikri]

Hi, and thanks for MyIP.

.github/workflows/docker-image.yml publishes 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.

MyIP is self-hosted so the lookups it performs stay on the operator's own box rather than going through a third-party service — the same reasoning that makes the image's origin worth confirming.

The change is two lines on the build step:

          push: ...
          provenance: mode=max
          sbom: true

BuildKit attaches both to the image manifest, so they travel with the image. No permissions change is needed — nothing has to gain id-token, and your tag and cache configuration are untouched.

docker buildx imagetools inspect <image>:<tag> --format '{{ json .Provenance }}'

Two caveats worth stating: mode=max records the full build including build arguments, so provenance: true is the smaller option if any have ever been sensitive; and attestations add an extra manifest to the index, which the registry supports.

No SLSA level claimed — 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.

[greptile-apps]

Greptile Summary

Adds BuildKit provenance and SBOM attestations to published Docker images.

• Enables maximum-detail provenance metadata.
• Generates an SBOM for images published to Docker Hub and GHCR.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
.github/workflows/docker-image.yml	Enables provenance and SBOM attestations without changing image tags, registry authentication, cache configuration, or build inputs.

_{Reviews (2): Last reviewed commit: "ci: restore trailing newline at end of f..." | Re-trigger Greptile}

[kobihikri]

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, docker/build-push-action adds provenance attestations with mode=max by default — Docker's documentation states it plainly: "Public repos: provenance attestations with mode=max are automatically added". I checked published images and they do already carry attestation manifests. So the provenance: mode=max line in my diff makes existing behaviour explicit; it does not add anything new.

The SBOM is genuinely new. That part stands — the same page says "SBOM attestations aren't automatically added to the image", and sbom: true is what enables them.

I also wrote in the caveats that provenance: true gives "a smaller record". That is wrong as well: true resolves to max on a public repo, and the smaller setting is provenance: mode=min.

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.

[jason5ng32]

Thanks for the PR and for the honest framing (including the "no SLSA level claimed" note) — appreciated.

After looking into it, I'm leaning toward not merging this, for two reasons:

1. The value lands in an awkward middle. BuildKit provenance is self-reported, unsigned metadata: anyone building an image elsewhere could produce an identical-looking attestation, so it doesn't actually let a puller verify the image came from this workflow — which is the stated motivation. For real verifiability this would need signed attestations (e.g. actions/attest-build-provenance with id-token: write, or cosign). I'd rather either go to that strength or not add attestations at all; the halfway point adds bytes without adding proof.

2. The unknown/unknown platform entries. Attestation manifests show up as extra unknown/unknown entries in the Docker Hub / GHCR UI. MyIP has a lot of self-hosting users, and experience says this reliably generates "why does the image have an unknown architecture" issues — cosmetic, but recurring noise I'd rather not take on for metadata that isn't cryptographic proof.

If you're interested in doing the signed-attestation version properly, I'd be happy to look at that as a separate proposal. Thanks again for taking the time to look at the workflow.