README.md 8.94 KB
Newer Older
Mark Lodato's avatar
Mark Lodato committed
1
2
3
4
5
6
7
8
9
10
11
12
# 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
Mark Lodato's avatar
Mark Lodato committed
13
[OpenSSF Digital Identity WG](https://github.com/ossf/wg-digital-identity-attestation).
Kim Lewandowski's avatar
Kim Lewandowski committed
14

Mark Lodato's avatar
Mark Lodato committed
15
## Overview
Kim Lewandowski's avatar
Kim Lewandowski committed
16

Mark Lodato's avatar
Mark Lodato committed
17
SLSA consists of:
Mark Lodato's avatar
Mark Lodato committed
18

19
20
21
1.  **[Standards][spec/README.md]:** Industry consensus on the definition of a
    "secure" software supply chain. There may be multiple standards to represent
    multiple aspects of security.
Mark Lodato's avatar
Mark Lodato committed
22
23
2.  **Accreditation:** Process for organizations to certify compliance with
    these standards.
24
25
3.  **[Technical controls](controls/README.md):** To record provenance and
    detect or prevent non-compliance.
Mark Lodato's avatar
Mark Lodato committed
26
27
28

Ultimately, the software consumer decides whom to trust and what standards to
enforce. In this light, accreditation is a means to transfer trust across
Mark Lodato's avatar
Mark Lodato committed
29
organizational boundaries. For example, a company may internally "accredit" its
Mark Lodato's avatar
Mark Lodato committed
30
31
32
in-house source and build systems while relying on OpenSSF to accredit
third-party ones. Other organizations may trust other accreditation bodies.

33
34
For more background and motivation, see [Background](background.md) and
[FAQ](faq.md).
Kim Lewandowski's avatar
Kim Lewandowski committed
35

Mark Lodato's avatar
Mark Lodato committed
36
## Principles
Kim Lewandowski's avatar
Kim Lewandowski committed
37

Mark Lodato's avatar
Mark Lodato committed
38
SLSA focuses on the following two main principles:
Kim Lewandowski's avatar
Kim Lewandowski committed
39

Mark Lodato's avatar
Mark Lodato committed
40
41
*   **Non-unilateral:** No person can modify the software artifact anywhere in
    the software supply chain without explicit review and approval by at least
Mark Lodato's avatar
Mark Lodato committed
42
    one other "trusted person."[^1] The purpose is prevention, deterrence,
Mark Lodato's avatar
Mark Lodato committed
43
    and/or early detection of risky/bad changes.
Kim Lewandowski's avatar
Kim Lewandowski committed
44

Mark Lodato's avatar
Mark Lodato committed
45
46
47
48
*   **Auditable:** The software artifact can be securely and transparently
    traced back to the original, human readable sources and dependencies. The
    primary purpose is for automated analyses of sources and dependencies, as
    well as ad-hoc investigations.
Kim Lewandowski's avatar
Kim Lewandowski committed
49

Mark Lodato's avatar
Mark Lodato committed
50
51
Though not perfect, these two principles provide substantial mitigation for a
wide range of tampering, confusion, and other supply chain attacks.
Kim Lewandowski's avatar
Kim Lewandowski committed
52

Mark Lodato's avatar
Mark Lodato committed
53
54
55
56
57
To measure how well protected a supply chain is according to the two principles
above, we propose the SLSA levels. A higher level means it is better protected.
SLSA 3 is the end goal but may take many years and significant investment for
large organizations. SLSA 1 and SLSA 2 are stepping stones to recognize
meaningful progress.
Kim Lewandowski's avatar
Kim Lewandowski committed
58

Mark Lodato's avatar
Mark Lodato committed
59
60
What sets SLSA 3 apart from simple best practices is its resilience against
determined adversaries. That is, SLSA is a **guarantee** that these practices
Mark Lodato's avatar
Mark Lodato committed
61
have been followed, though still not a guarantee that the software is "safe."
Kim Lewandowski's avatar
Kim Lewandowski committed
62

63
## Summary of requirements
Kim Lewandowski's avatar
Kim Lewandowski committed
64

65
See [spec/README.md] for details.
Kim Lewandowski's avatar
Kim Lewandowski committed
66

67
<!-- When editing this table, also edit spec/README.md. -->
Kim Lewandowski's avatar
Kim Lewandowski committed
68
69

<table>
Mark Lodato's avatar
Mark Lodato committed
70
 <thead>
71
72
  <tr><th colspan="2">           <th colspan="4">Required at</tr>
  <tr><th colspan="2">Requirement<th>SLSA 1<th>SLSA 1.5<th>SLSA 2<th>SLSA 3</tr>
Mark Lodato's avatar
Mark Lodato committed
73
74
 </thead>
 <tbody>
75
  <tr><td rowspan="4">Source
76
77
78
79
      <td>Version Controlled        <td> <td><td><td></tr>
  <tr><td>Verified History          <td> <td> <td><td></tr>
  <tr><td>Retained Indefinitely     <td> <td> <td>18 mo.<td></tr>
  <tr><td>Two-Person Reviewed       <td> <td> <td>      <td></tr>
80
  <tr><td rowspan="6">Build
81
82
      <td>Scripted                  <td><td><td><td></tr>
  <tr><td>Build Service             <td> <td><td><td></tr>
Mark Lodato's avatar
Mark Lodato committed
83
  <tr><td>Ephemeral Environment     <td> <td> <td><td></tr>
84
85
86
  <tr><td>Isolated                  <td> <td> <td><td></tr>
  <tr><td>Hermetic                  <td> <td> <td>      <td></tr>
  <tr><td>Reproducible              <td> <td> <td>      <td></tr>
87
  <tr><td rowspan="5">Provenance
88
89
90
91
      <td>Available                 <td><td><td><td></tr>
  <tr><td>Authenticated             <td> <td><td><td></tr>
  <tr><td>Service Generated         <td> <td><td><td></tr>
  <tr><td>Non-Falsifiable           <td> <td> <td><td></tr>
Mark Lodato's avatar
Mark Lodato committed
92
  <tr><td>Dependencies Complete     <td> <td> <td>      <td></tr>
93
  <tr><td rowspan="3">Common
Mark Lodato's avatar
Mark Lodato committed
94
95
96
      <td>Security                  <td> <td> <td>      <td></tr>
  <tr><td>Access                    <td> <td> <td>      <td></tr>
  <tr><td>Superusers                <td> <td> <td>      <td></tr>
Mark Lodato's avatar
Mark Lodato committed
97
 </tbody>
Kim Lewandowski's avatar
Kim Lewandowski committed
98
99
</table>

100
## Why do we need SLSA?
Kim Lewandowski's avatar
Kim Lewandowski committed
101

102
SLSA addresses three issues:
Kim Lewandowski's avatar
Kim Lewandowski committed
103

104
105
106
107
108
109
*   Software producers want to secure their supply chains but don't know exactly
    how.
*   Software consumers want to understand and limit their exposure to supply
    chain attacks but have no means of doing so.
*   Artifact signatures alone only prevent a subset of the attacks we care
    about.
Kim Lewandowski's avatar
Kim Lewandowski committed
110

111
112
113
114
At a minimum, SLSA can be used as a set of guiding principles for software
producers and consumers. More importantly, SLSA allows us to talk about supply
chain risks and mitigations in a common language. This allows us to communicate
and act on those risks across organizational boundaries.
Mark Lodato's avatar
Mark Lodato committed
115

116
117
118
119
Numeric levels, in particular, are useful because they are simple. A decision
maker easily understands that SLSA 3 is better than SLSA 2 without understanding
any of the details. That said, we are not committed to numeric levels and are
open to other options.
Mark Lodato's avatar
Mark Lodato committed
120

121
122
123
124
Once SLSA is complete it will provide a mapping from requirements that the
supply chain can implement to the attacks they can prevent. Software producers
and consumers will be able to look at the SLSA level of a software artifact and
know what attacks have been defended against in its production.
Kim Lewandowski's avatar
Kim Lewandowski committed
125

126
## How to get started
Kim Lewandowski's avatar
Kim Lewandowski committed
127

128
129
**Developers:** For instructions on how to produce and verify SLSA-compliant
software... **\[TODO]**.
Kim Lewandowski's avatar
Kim Lewandowski committed
130

131
132
**Implementers:** For detailed requirements on how source and build systems can
meet SLSA, see [spec/README.md].
Kim Lewandowski's avatar
Kim Lewandowski committed
133

134
We welcome all comments and suggestions for this document via GitHub issues,
Mark Lodato's avatar
Mark Lodato committed
135
136
pull requests, [email][mailing list], or [feedback form]. Join the
[mailing list] to follow the discussion and progress.
Kim Lewandowski's avatar
Kim Lewandowski committed
137

Mark Lodato's avatar
Mark Lodato committed
138
## Related work
Kim Lewandowski's avatar
Kim Lewandowski committed
139

Mark Lodato's avatar
Mark Lodato committed
140
141
142
143
In parallel to the SLSA specification, there is work to develop core formats and
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.
Kim Lewandowski's avatar
Kim Lewandowski committed
144

Mark Lodato's avatar
Mark Lodato committed
145
146
*   [Standard attestation format](https://github.com/in-toto/attestation#in-toto-attestations)
    to express provenance and other attributes. This will allow sources and
Mark Lodato's avatar
Mark Lodato committed
147
148
149
    builders to express properties in a standard way that can be consumed by
    anyone. Also includes reference implementations for generating these
    attestations.
Kim Lewandowski's avatar
Kim Lewandowski committed
150
151
152
153
*   Policy data model and reference implementation.

For a broader view of the software supply chain problem:

Mark Lodato's avatar
Mark Lodato committed
154
155
156
*   [Know, Prevent, Fix: A framework for shifting the discussion around
    vulnerabilities in open
    source](https://security.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting.html)
157
*   [Threats, Risks, and Mitigations in the Open Source Ecosystem]
Kim Lewandowski's avatar
Kim Lewandowski committed
158
159
160

Prior iterations of the ideas presented here:

161
*   [Building Secure and Reliable Systems, Chapter 14: Deploying Code](https://sre.google/static/pdf/building_secure_and_reliable_systems.pdf#page=339)
162
163
*   [Binary Authorization for Borg] - This is how Google implements the SLSA
    idea internally.
Kim Lewandowski's avatar
Kim Lewandowski committed
164
165
166
167

Other related work:

*   [CII Best Practices Badge](https://bestpractices.coreinfrastructure.org/en)
Mark Lodato's avatar
Mark Lodato committed
168
169
170
*   [Security Scorecards](https://github.com/ossf/scorecard) - Perhaps SLSA
    could be implemented as an aggregation of scorecard entries, for at least
    the checks that can be automated.
Kim Lewandowski's avatar
Kim Lewandowski committed
171
172
173
174
175
176
177
*   [Trustmarks](https://trustmark.gtri.gatech.edu/)

Other takes on provenance and CI/CD:

*   [The Path to Code Provenance](https://medium.com/uber-security-privacy/code-provenance-application-security-77ebfa4b6bc5)
*   [How to Build a Compromise-Resilient CI/CD](https://www.youtube.com/watch?v=9hCiHr1f0zM)

Mark Lodato's avatar
Mark Lodato committed
178
## Footnotes
Kim Lewandowski's avatar
Kim Lewandowski committed
179

Mark Lodato's avatar
Mark Lodato committed
180
[^1]: "Trusted person" is defined by the organization or developers that
Mark Lodato's avatar
Mark Lodato committed
181
182
    own/produce the software. A consumer must ultimately trust them to do the
    right thing. The non-unilateral principle protects against individuals
Mark Lodato's avatar
Mark Lodato committed
183
    within the organization subverting the organization's goals.
184
185
186
187
188
189
190

<!-- Links -->

[Binary Authorization for Borg]: https://cloud.google.com/security/binary-authorization-for-borg
[Threats, Risks, and Mitigations in the Open Source Ecosystem]: https://github.com/Open-Source-Security-Coalition/Open-Source-Security-Coalition/blob/master/publications/threats-risks-mitigations/v1.1/Threats%2C%20Risks%2C%20and%20Mitigations%20in%20the%20Open%20Source%20Ecosystem%20-%20v1.1.pdf
[feedback form]: https://forms.gle/93QRfUqF7YY2mJDi9
[mailing list]: https://groups.google.com/g/slsa-discussion
191
[spec/README.md]: spec/README.md