How to SLSA Part 3 - Putting it all together

Posted by Tom Hennen, software engineer, BCID & GOSST 
In our last two posts () we introduced a fictional example of Squirrel, Oppy, and Acme learning to SLSA and covered the basics and details of how they’d use SLSA for their organizations. Today we’ll close out the series by exploring how each organization pulls together the various solutions into a heterogeneous supply chain.

As a reminder, Acme is trying to produce a container image that contains three artifacts:

1. The Squirrel package ‘foo’
2. The Oppy package ‘baz’
3. A custom executable, ‘bar’, written by Acme employees.

The process starts with ‘foo’ package authors triggering a build using GitHub Actions. This results in a new version of ‘foo’ (an artifact with hash ‘abc’) being pushed to the Squirrel repo along with its SLSA provenance (signed by Fulcio) and .

Copying the reported dependencies of acorn://foo@abc and oppy://baz@def into .

Recording the CI/CD entrypoint as the with the SLSA provenance and adding it to the output for the container leveraging data about the build as stored in Rekor. Acme then publishes the container image, the VSA, and the SBOM on Dockerhub.

Downstream users of this Acme container can then check the Acme issued VSA, and if there are any problems Acme can consult their internal Rekor instance to get more details on the build allowing Acme to trace all of their dependencies back to source code and the systems used to create them.
Conclusion

With SLSA implemented in the ways described in this series, downstream users are protected from many of how you like to SLSA. 

Vollständiger Original-Bericht

Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf security.googleblog.com.

↗ Original-Artikel auf security.googleblog.com lesen