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.