ci: attach provenance and SBOM attestations to the published images

[kobihikri]

Hi, and thanks for umami.

.github/workflows/cd.yml builds and pushes two image variants — the PostgreSQL and MySQL builds — to both ghcr.io and Docker Hub, but none of the pushed manifests carry a provenance or SBOM attestation.

umami is analytics people self-host precisely so the data stays theirs, and the image is what they deploy. Being able to confirm the image was built by this workflow from this repository fits the reason someone chose to self-host in the first place.

The change is two lines on each of the two build steps:

          push: true
          provenance: mode=max
          sbom: true

BuildKit attaches the attestation to the image manifest, so each build covers both registries it pushes to — no second credential and no extra step. No permissions change is needed: the job's contents: read and packages: write stay exactly as they are, and nothing needs id-token. Your tag-assembly logic and the GHCR_TAGS / Docker Hub tag lists are untouched.

Consumers can then check either variant with:

docker buildx imagetools inspect ghcr.io/umami-software/umami:postgresql-latest --format '{{ json .Provenance }}'

Two caveats worth stating: mode=max records the full build including build args (provenance: true gives a smaller record if any have ever been sensitive), and attestations add an extra manifest to the index — both GHCR and Docker Hub support this.

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 and both push targets myself.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[vercel]

@kobihikri is attempting to deploy a commit to the Umami Software Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Greptile Summary

Adds BuildKit provenance and SBOM attestations to both multi-platform image publication steps.

• Enables maximum-detail provenance for images pushed to GHCR and Docker Hub.
• Enables SBOM generation for both registry targets.

Confidence Score: 5/5

The PR appears safe to merge with no actionable defects identified.

Both publication steps use attestation-capable Docker build actions with pushed multi-platform images, and the repository does not pass sensitive values through Docker build arguments that maximum-detail provenance would disclose.

Important Files Changed

Filename	Overview
.github/workflows/cd.yml	Enables supported provenance and SBOM inputs on both existing image publication steps without changing tags, credentials, or build contexts.

_{Reviews (1): Last reviewed commit: "ci: attach provenance and SBOM attestati..." | 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.