Security Blog
The latest news and insights from Google on security and safety on the Internet
How to SLSA Part 3 - Putting it all together
14 април 2022 г.
Posted by Tom Hennen, software engineer, BCID & GOSST
In our last two posts (
1
,
2
) 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:
The Squirrel package ‘foo’
The Oppy package ‘baz’
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
source attestation
. When Squirrel gets this push request it verifies the artifact against the specific policy for ‘foo’ which checks that it was built by GitHub Actions from the expected source repository. After the artifact passes the policy check a VSA is created and the new package, its original SLSA provenance, and the VSA are made public in the Squirrel repo, available to all users of package ‘foo’.
Next the maintainers of the Oppy ‘baz’ package trigger a new build using the Oppy Autobuilder. This results in a new version of ‘baz’ (an artifact with hash ‘def’) being pushed to a public Oppy repo with the SLSA provenance (signed by their org-specific keys) published to Rekor. When the repo gets the push request it makes the artifact available to the public. The repo does not perform any verification at this time.
An Acme employee then makes a change to their Dockerfile, sending it for review by their co-worker, who approves the change and merges the PR. This then causes the Acme builder to trigger a build. During this build:
bar is compiled from source code stored in the same source repo as the Dockerfile.
acorn install downloads ‘foo’ from the Squirrel repo, verifying the VSA, and recording the use of acorn://foo@abc and its VSA in the build.
acme_oppy_get install (a custom script made by Acme) downloads the latest version of the Oppy ‘baz’ package and queries its SLSA provenance and other attestations from Rekor. It then performs a full verification checking that it was built by ‘https://oppy.example/slsa/builder/v1’ and the publicized key. Once verification is complete it records the use of oppy://baz@def and the associated attestations in the build.
The build process assembles the SLSA provenance for the container by:
Recording the Acme git repo the bar source and Dockerfile came from, into
materials
.
Copying the reported dependencies of acorn://foo@abc and oppy://baz@def into
materials
and adding their attestations to the output
in-toto bundle
.
Recording the CI/CD entrypoint as the
invocation
.
Creating a signed
DSSE
with the SLSA provenance and adding it to the output
in-toto bundle
.
Once the container is ready for release the Acme verifier checks the SLSA provenance (and other data in the in-toto bundle) using the policy from their own policy repo and issues a VSA. The VSA and all associated attestations are then published to an internal Rekor instance. Acme can then create an
SBOM
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
the threats affecting the software supply chain today
. While users still need to trust certain parties, the number of systems requiring trust is much lower and users are in a much better position to investigate any issues that arise.
We’d love to see the ideas in this series implemented, refuted, or used as a foundation to build even stronger solutions. We’d also love to hear some other methods on how to solve these issues.
Show us
how you like to SLSA.
Няма коментари :
Публикуване на коментар
Етикети
#sharethemicincyber
#supplychain #security #opensource
android
android security
android tr
app security
big data
biometrics
blackhat
C++
chrome
chrome enterprise
chrome security
connected devices
CTF
diversity
encryption
federated learning
fuzzing
Gboard
google play
google play protect
hacking
interoperability
iot security
kubernetes
linux kernel
memory safety
Open Source
pha family highlights
pixel
privacy
private compute core
Rowhammer
rust
Security
security rewards program
sigstore
spyware
supply chain
targeted spyware
tensor
Titan M2
VDP
vulnerabilities
workshop
Archive
2024
ное
окт
сеп
авг
юли
юни
май
апр
март
фев
яну
2023
дек
ное
окт
сеп
авг
юли
юни
май
апр
март
фев
яну
2022
дек
ное
окт
сеп
авг
юли
юни
май
апр
март
фев
яну
2021
дек
ное
окт
сеп
авг
юли
юни
май
апр
март
фев
яну
2020
дек
ное
окт
сеп
авг
юли
юни
май
апр
март
фев
яну
2019
дек
ное
окт
сеп
авг
юли
юни
май
апр
март
фев
яну
2018
дек
ное
окт
сеп
авг
юли
юни
май
апр
март
фев
яну
2017
дек
ное
окт
сеп
юли
юни
май
апр
март
фев
яну
2016
дек
ное
окт
сеп
авг
юли
юни
май
апр
март
фев
яну
2015
дек
ное
окт
сеп
авг
юли
юни
май
апр
март
фев
яну
2014
дек
ное
окт
сеп
авг
юли
юни
апр
март
фев
яну
2013
дек
ное
окт
авг
юни
май
апр
март
фев
яну
2012
дек
сеп
авг
юни
май
апр
март
фев
яну
2011
дек
ное
окт
сеп
авг
юли
юни
май
апр
март
фев
2010
ное
окт
сеп
авг
юли
май
апр
март
2009
ное
окт
авг
юли
юни
март
2008
дек
ное
окт
авг
юли
май
фев
2007
ное
окт
сеп
юли
юни
май
Feed
Follow @google
Follow
Give us feedback in our
Product Forums
.
Follow
Няма коментари :
Публикуване на коментар