From 529afa03a33146601e0ae2d913772b098958cb0f Mon Sep 17 00:00:00 2001 From: Mark Lodato Date: Wed, 9 Jun 2021 12:51:03 -0400 Subject: [PATCH] Remove "proposed" wording. Minor changes to remove the notion that this is a "proposal" and instead just describe SLSA as it is. Also explain that levels 2-3 are likely to change in the future, rather than using some sort of symbol (*) or term (provisional), since technically all requirements are subject to change. It's just that 2-3 are more likely to change. --- README.md | 74 ++++++++++++++++++++++++++----------------------------- 1 file changed, 35 insertions(+), 39 deletions(-) diff --git a/README.md b/README.md index 60d68ce08..b6599e61e 100644 --- a/README.md +++ b/README.md @@ -1,23 +1,20 @@ -# SLSA: Supply-chain Levels for Software Artifacts, Proposal - -## Objective - -The objective of this document is to reach industry agreement on the framework -for software supply chain security through standards, accreditation, and -technical controls. This is being developed as part of the +# SLSA: Supply-chain Levels for Software Artifacts + +Supply-chain Levels for Software Artifacts (SLSA, pronounced +_[salsa](https://www.google.com/search?q=how+to+pronounce+salsa)_) is an +end-to-end framework for ensuring the integrity of software artifacts throughout +the software supply chain. The requirements are inspired by Google’s internal +"[Binary Authorization for Borg]" that has been in use for the past 8+ years and +that is mandatory for all of Google's production workloads. + +**IMPORTANT:** SLSA is an evolving specification and we are looking for +wide-ranging feedback via GitHub issues, [email][mailing list], or +[feedback form]. SLSA is being developed as part of the [OpenSSF Digital Identity WG](https://github.com/ossf/wg-digital-identity-attestation). ## Overview -This is just a proposed starting point using one example for discussion. We are -looking for wide-ranging feedback via GitHub issues, [email][mailing list], or -[feedback form]. - -Our draft proposal is called SLSA: Supply-chain Levels for Software Artifacts, -pronounced _[salsa](https://www.google.com/search?q=how+to+pronounce+salsa)_. It -ensures that software artifacts meet certain minimum end-to-end integrity -standards, inspired by what Google does -[internally][Binary Authorization for Borg]. It consists of: +SLSA consists of: 1. **Standards:** (this doc) Industry consensus on the definition of a "secure" software supply chain. There may be multiple standards to represent multiple @@ -40,7 +37,7 @@ chain. ## Principles -We suggest initially focusing on the following two main principles: +SLSA focuses on the following two main principles: * **Non-unilateral:** No person can modify the software artifact anywhere in the software supply chain without explicit review and approval by at least @@ -189,9 +186,8 @@ bit-for-bit identical output. This property including easier debugging, more confident cherry-pick releases, better build caching and storage efficiency, and accurate dependency tracking. -For these reasons, SLSA 3 [requires](#proposed-slsa-definitions) reproducible -builds unless there is a justification why the build cannot be made -reproducible. +For these reasons, SLSA 3 [requires](#level-requirements) reproducible builds +unless there is a justification why the build cannot be made reproducible. [Example](https://lists.reproducible-builds.org/pipermail/rb-general/2021-January/002177.html) justifications include profile-guided optimizations or code signing that invalidates hashes. Note that there is no actual reproduction, just a claim that @@ -287,10 +283,11 @@ Special cases: * A ZIP file is containing source code is a package, not a source, because it is built from some other source, such as a git commit. -## Proposed SLSA definitions +## SLSA definitions _Reminder: The definitions below are not yet finalized and subject to change. In -particular, the levels will be renumbered to be all integers._ +particular, (1) we expect to renumber the levels to be integers; and (2) levels +2-3 are likely to undergo further changes._ An artifact's **SLSA level** describes the integrity strength of its direct supply chain, meaning its direct sources and build steps. To verify that the @@ -302,8 +299,8 @@ that the level's requirements have been met. _This section is non-normative._ There are four SLSA levels. SLSA 3 is the current highest level and represents -the ideal end state. SLSA 1–2 offer lower security guarantees but are easier -to meet. In our experience, achieving SLSA 3 can take many years and significant +the ideal end state. SLSA 1–2 offer lower security guarantees but are easier to +meet. In our experience, achieving SLSA 3 can take many years and significant effort, so intermediate milestones are important. @@ -506,16 +503,16 @@ be enabled. In the updated diagram, the provenance now lists some dependencies, such as the base image (`alpine:3.11.5`) and apk packages (e.g. `curl-dev`). -At SLSA 2, the provenance is significantly more trustworthy than -before. Only highly skilled adversaries are likely able to forge it. +At SLSA 2, the provenance is significantly more trustworthy than before. Only +highly skilled adversaries are likely able to forge it. #### SLSA 3: Hermeticity and two-person review ![slsa3](images/slsa-3.svg) -SLSA 3 [requires](#proposed-slsa-definitions) two-party source control and -hermetic builds. Hermeticity in particular guarantees that the dependencies are -complete. Once these controls are enabled, the Docker image will be SLSA 3. +SLSA 3 [requires](#level-requirements) two-party source control and hermetic +builds. Hermeticity in particular guarantees that the dependencies are complete. +Once these controls are enabled, the Docker image will be SLSA 3. In the updated diagram, the provenance now attests to its hermeticity and includes the `cacert.pem` dependency, which was absent before. @@ -546,10 +543,10 @@ heuristics. ### Composition of SLSA levels -An artifact's SLSA level is not transitive, so some aggregate measure of security -risk across the whole supply chain is necessary. In other words, each node in -our graph has its own, independent SLSA level. Just because an artifact's level -is N does not imply anything about its dependencies' levels. +An artifact's SLSA level is not transitive, so some aggregate measure of +security risk across the whole supply chain is necessary. In other words, each +node in our graph has its own, independent SLSA level. Just because an +artifact's level is N does not imply anything about its dependencies' levels. In our example, suppose that the final [curlimages/curl] Docker image were SLSA 3 but its [curl-dev] dependency were SLSA 0. Then this would imply a significant @@ -576,11 +573,10 @@ for closed source software. ## Next steps We welcome all comments and suggestions for this document via GitHub issues, -pull requests, [email][mailing list], or [feedback form]. +pull requests, [email][mailing list], or [feedback form]. Join the +[mailing list] to follow the discussion and progress. -The future SLSA working group will formulate this document. Join the -[mailing list] to follow the discussion and progress. Issues that we must work -out: +Issues that we must work out: * Agree on the principles, terminology, and high-level strategy. * Define a threat model describing specific threats we intend to address. @@ -598,8 +594,8 @@ data models. Currently this is joint work between [Binary Authorization](https://cloud.google.com/binary-authorization) and [in-toto](https://in-toto.io/) but we invite wider participation. -* [Standard attestation format](https://github.com/in-toto/attestation#in-toto-attestations) to - express provenance and other attributes. This will allow sources and +* [Standard attestation format](https://github.com/in-toto/attestation#in-toto-attestations) + to express provenance and other attributes. This will allow sources and builders to express properties in a standard way that can be consumed by anyone. Also includes reference implementations for generating these attestations.