Concrete link between image and the configuration that produced it

[joshuagl]

Note: this is a feature request but does not match the current issue template.

Feature request: can we include the commit digest of the release tag the image was built from in the image? (i.e. environment variable or /imagegeneration/imagedata.json).

Context: I work on the SLSA project and slsa-github-generator-go, where we are building tools to support producing SLSA level 3 artefacts with GitHub Actions. (See GitHub blog post "Achieving SLSA 3 Compliance with GitHub Actions and Sigstore for Go modules" and Google blog post "Improving software supply chain security with tamper-proof builds" for more information).

We include a link to the virtual-environments release in the materials section of the SLSA provenance we generate and would also like to include a corresponding digest for that material. However, AFAICT the virtual-environment images do not include the SHA of the commit the release tag references.

We could resolve the tag to a commit SHA at provenance generation time (i.e. gh api -H "Accept: application/vnd.github.v3+json" /repos/actions/virtual-environments/git/matching-refs/tags/$ImageOS/$ImageVersion), but as tags can be overwritten – and therefore may not resolve to the same commit digest at API call time – this doesn't feel appropriate.

I'd be more than willing to submit a PR for this if the feature is agreeable, implementation pointers would be gratefully received.

[miketimofeev]

Hi @joshuagl!
The problem is that the commit might be misleading as lots of software is installed using the latest available version at the moment of the image generation. That is the reason why we don't recommend sticking to any releases and use always the main branch.

[joshuagl]

Hello @miketimofeev !

Is it possible, and indeed deemed worthwhile, to augment the images building to capture more version information about which versions are installed at image creation? (certainly yes for Linux images, but I'm less certain about non-Linux OS).

Per the SLSA model it is useful to have full information about the materials which are used in a build for policy and remediation (plus reproducibility, but that is a) not needed until SLSA level 4 and b) may not be possible for the images here given fetching latest at image generation).

[miketimofeev]

Well, our readme files are quite detailed and we try to include all the software versions in them, but any improvements are welcome