containers icon indicating copy to clipboard operation
containers copied to clipboard

How to perform provenance attestation on these images ?

Open webmutation opened this issue 10 months ago • 4 comments

Hello,

We are using these images as the base image, we patch and harden a bit and rebuild whenever there is a new release. However we would like to add attestation validation of provenance, are these images being generated with provenance information and sbom so we can validate it when updating our own images ?

lets say something simple with Github Actions

  - name: Build and push
    uses: docker/build-push-action@v6
    with:
      tags: "${{ vars.DOCKER_USER }}/${{ vars.DOCKER_IMAGENAME}}:${{ github.ref_name }}"
      # For pull requests, export results to the build cache.
      # Otherwise, push to a registry.
      outputs: ${{ github.event_name == 'pull_request' && 'type=cacheonly' || 'type=registry' }}
      **provenance: mode=max
      sbom: true**

webmutation avatar Apr 10 '25 14:04 webmutation

You're quite right to be looking for attestation metadata when using base images. In this case, the key detail is that the eclipse-temurin images you’re referencing (e.g. eclipse-temurin:17-jre-alpine@sha256:...) are part of the Docker Official Images programme.

That means the images themselves are built and published by Docker Inc, not by the Adoptium project directly. They use our upstream Dockerfiles from github.com/adoptium/containers, but the build and signing process is handled within Docker’s infrastructure. As a result:

  • The images are signed using Docker’s Content Trust (DCT), and you can enable DOCKER_CONTENT_TRUST=1 to enforce signature verification when pulling.
  • However, the signatures are owned by Docker, not Adoptium, and there’s no published SLSA-style attestation or SBOM linked directly to the source at this time.

We’re actively exploring how to publish our own signed container images with full provenance — including linking back to Build jobs and SBOMs — especially for consumers like yourself who need that level of assurance. In the meantime, if you're interested, you can:

  • Inspect the Dockerfiles to see exactly what goes into the image builds.
  • Use fixed digests (as you already are) for reproducibility.
  • Check for DOCKER_CONTENT_TRUST signatures when pulling, although note that the process has some rough edges in practice.

Thanks again for raising this — it’s an important area for us and I’ll make sure it stays on the agenda. Happy to follow up as our work in this space progresses.

gdams avatar Apr 16 '25 13:04 gdams

Thank you very much @gdams , indeed we went that route and are now considering building from scratch using this repository so we have SLSA attestation. However if there is something in the works already we will wait until end of summer.

Image

webmutation avatar May 06 '25 11:05 webmutation

pinging @tianon / @yosifkit to clarify if there's anything else in the Official Images pipeline that I might have missed

gdams avatar May 06 '25 11:05 gdams

DOI are published with SBOM and provenance attestations. See, for example https://oci.dag.dev/?image=eclipse-temurin%3A17-jre-alpine. The second, "unknown/unknown" image in the image index contains the SBOM and provenance attestations, https://oci.dag.dev/?image=eclipse-temurin@sha256:23ae261fe0fe077592edf8b50fc2f777ac7eb8cebe3363c4d728e29d68c4e600&mt=application%2Fvnd.oci.image.manifest.v1%2Bjson&size=840

whalelines avatar May 23 '25 22:05 whalelines