Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: Add signed SLSA attestations to nightly docker builds #125

Closed
asraa opened this issue Jul 28, 2022 · 4 comments
Closed

Enhancement: Add signed SLSA attestations to nightly docker builds #125

asraa opened this issue Jul 28, 2022 · 4 comments
Assignees

Comments

@asraa
Copy link

asraa commented Jul 28, 2022

Hi! I'm reaching out on behalf of the Open Source Security Foundation (openssf.org). We work on improving supply-chain security of critical open source projects. We believe we can help improve the tamper resistance of TF's nightly docker builds, with just a few lines of code. Starting with nightly docker builds is relatively low-risk, and allows some testing of the verification flow before moving to the more stable images.

These docker builds are built in this repository via GitHub Actions. Adding a provenance attestation during the build process allows a cryptographically verifiable guarantee that the image was built in this repository. This provenance is a file with metadata that lets users know that the container images were built from your repository’s workflow and not altered by anyone.

The container provenance generator workflow uploads the attestation in the registry using Sigstore's attestation specification. This is projected to go GA in the next few weeks (the API may be change in future releases of the generator), and we would love to use TF's nightly builds as an early adoption.

Generating these attestations is also a step toward adopting Supply-chain Levels for Software Artifacts (SLSA). SLSA is a security framework to improve transparency and authenticity of the build / release process. It’s designed and used by a consortium of companies including Google, Intel, Chainguard, Citi, and Datadog, under the umbrella of the Open Source Security Foundation. By generating these attestations in the future for stable docker builds, your project will reach SLSA Level 3 for provenance. You can even add a SLSA badge to your repository so users know that you take security seriously.

If you're interested in reading more, check out this recent blog post, which describes how some of the recent supply-chain attacks would have been prevented using SLSA provenance.

Happy to answer any question you might have.

I'll follow up with a PR and link here to show the changes needed to add provenance to the docker workflow.

cc @ianlewis @mihaimaruseac @laurentsimon

@mihaimaruseac mihaimaruseac self-assigned this Jul 29, 2022
@bhack
Copy link
Contributor

bhack commented Aug 1, 2022

Is this only related to the docker nightly images or also to the Tensorflow nightly wheels built with these images?

Cause we still don't publicly know on which specific nightly commits the nightly wheels are built. See #72

@mihaimaruseac
Copy link
Collaborator

They're not really related. The wheels need a lot more work to get attestations added.

@asraa
Copy link
Author

asraa commented Aug 2, 2022

Is this only related to the docker nightly images or also to the Tensorflow nightly wheels built with these images?

This would just be the docker nightly images.

Right now we can create attestations on a general hashable artifacts (which could apply to the wheels), golang binaries, and OCI artifacts. We are working to create better SLSA attestations for the python ecosystem separately, so that attestations can directly be retrieved through pip. When the Python work is feature complete, we would definitely look into adding them.

Re the issue: the aim is that slsa attestations will provide information on the config source where it was built, including the commit SHA.

mihaimaruseac added a commit to tensorflow/tensorflow that referenced this issue Sep 22, 2022
Should close tensorflow/build#125

TODO: the same for all other containers we maintain, maybe?

Signed-off-by: Mihai Maruseac <[email protected]>
mihaimaruseac added a commit to tensorflow/tensorflow that referenced this issue Dec 29, 2022
Should close tensorflow/build#125

TODO: the same for all other containers we maintain, maybe?

Signed-off-by: Mihai Maruseac <[email protected]>
@mihaimaruseac mihaimaruseac reopened this Jan 18, 2023
@mihaimaruseac
Copy link
Collaborator

(closed by mistake on my fork)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants