/
levels.md
286 lines (199 loc) · 10.4 KB
/
levels.md
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
# Security levels
SLSA is organized into a series of levels that provide increasing supply chain
security guarantees. This gives you confidence that software hasn’t been
tampered with and can be securely traced back to its source.
This page is an informative overview of the SLSA levels, describing their
purpose and guarantees. For the normative requirements at each level, see
[Requirements](requirements.md). For a background, see
[Terminology](terminology.md).
## What is SLSA?
SLSA is a set of incrementally adoptable security guidelines, established by
industry consensus. The standards set by SLSA are guiding principles for both
software producers and consumers: producers can follow the guidelines to make
their software more secure, and consumers can make decisions based on a software
package's security posture. SLSA's levels are designed to be incremental
and actionable, and to protect against specific classes of supply chain attacks.
The highest level in each track represents an ideal end state, and the lower
levels represent intermediate milestones with commensurate security guarantees.
Importantly, SLSA is intended to be a primitive in a broader determination of a
software's risk. SLSA measures specific aspects of supply chain security,
particularly those that can be fully automated; other aspects, such as developer
trust and code quality, are out of scope. Furthermore, each link in the software
supply chain has its own, independent SLSA level---in other words, it is not
transitive ([FAQ](faq.md#q-why-is-slsa-not-transitive)). The benefit of this
approach is to break up the large supply chain security problem into tractable
subproblems that can be prioritized based on risk and tackled in parallel. But
this does mean that SLSA alone is not sufficient to determine if an artifact is
"safe".
Finally, SLSA is in the eye of the beholder: software consumers ultimately make
their own SLSA determinations, though in practice they may delegate to some
authority. For example, a build system may claim to conform to SLSA Build L3,
but it is up to a consumer whether to trust that claim.
## Who is SLSA for?
SLSA is intended to serve multiple populations:
- **Project maintainers,** who are often small teams that know their build
process and trust their teammates. Their primary goal is protection against
compromise with as low overhead as possible. They may also benefit from
easier maintenance and increased consumer confidence.
- **Consumers,** who use a variety of software and do not know the maintainers
or their build processes. Their primary goal is confidence that the software
has not been tampered with. They are concerned about rogue maintainers,
compromised credentials, and compromised infrastructure.
- **Organizations,** who are both producers and consumers of software. In
addition to the goals above, organizations also want to broadly understand
and reduce risk across the organization.
- **Infrastructure providers,** such as build services and package
ecosystems, who are critical to achieving SLSA. While not the primary
beneficiary of SLSA, they may benefit from increased security and user
trust.
## Levels and tracks
SLSA levels are split into *tracks*. Each track has its own set of levels that
measure a particular aspect of supply chain security. The purpose of tracks is
to recognize progress made in one aspect of security without blocking on an
unrelated aspect. Tracks also allow the SLSA spec to evolve: we can add more
tracks without invalidating previous levels.
| Track/Level | Requirements | Benefits
| ----------- | ------------ | --------
| [Build L0] | (none) | (n/a)
| [Build L1] | Attestation showing that the package was built as expected | Documentation, mistake prevention, inventorying
| [Build L2] | Signed attestation, generated by a hosted build service | Reduced attack surface, weak tamper protection
| [Build L3] | Hardened build service | Strong tamper protection
> Note: The [previous version] of the specification used a single unnamed track,
> SLSA 1–4. For version 1.0 the Source aspects were removed to focus on the
> Build track. A Source track may be added in [future versions].
## Build track
The SLSA build track describes the level of protection against tampering
during or after the build, and the trustworthiness of provenance metadata.
Higher SLSA build levels provide increased confidence that a package truly came
from the correct sources, without unauthorized modification or influence.
> **TODO:** Add a diagram visualizing the following.
Summary of the build track:
- Set **project-specific expectations** for how the package should be built.
- Generate a **provenance attestation** automatically during each build.
- **Automatically verify** that each package's provenance meets expectations
before allowing its publication and/or consumption.
What sets the levels apart is how much trust there is in the accuracy of the
provenance and the degree to which adversaries are detected or prevented from
tampering with the package. Higher levels require hardened builds and protection
against more sophisticated adversaries.
Each ecosystem (for open source) or organization (for closed source) defines
exactly how this is implemented, including: means of defining expectations, what
provenance format is accepted, whether reproducible builds are used, how
provenance is distributed, when verification happens, and what happens on
failure. Guidelines for implementers can be found in the
[requirements](requirements.md).
<section id="build-l0">
### Build L0: No guarantees
<dl class="as-table">
<dt>Summary<dd>
No requirements---L0 represents the lack of SLSA.
<dt>Intended for<dd>
Development or test builds of software that are built and run on the same
machine, such as unit tests.
<dt>Requirements<dd>
n/a
<dt>Benefits<dd>
n/a
</dl>
</section>
<section id="build-l1">
### Build L1: Provenance
<dl class="as-table">
<dt>Summary<dd>
Package has a provenance attestation showing how it was built, and a downstream
system automatically verifies that packages were built as expected. Prevents
mistakes but is trivial to bypass or forge.
<dt>Intended for<dd>
Projects and organizations wanting to easily and quickly gain some benefits of
SLSA---other than tamper protection---without changing their build workflows.
<dt>Requirements<dd>
- Up front, the package maintainer defines how the package is *expected* to be
built, including the canonical source repository and build command.
- On each build, the release process automatically generates and distributes a
[provenance attestation] describing how the artifact was *actually* built,
including: who built the package (person or system), what process/command
was used, and what the input artifacts were.
- Downstream tooling automatically verifies that the artifact's provenance
exists and matches the expectation.
<dt>Benefits<dd>
- Makes it easier for both maintainers and consumers to debug, patch, rebuild,
and/or analyze the software by knowing its precise source version and build
process.
- Prevents mistakes during the release process, such as building from a commit
that is not present in the upstream repo.
- Aids organizations in creating an inventory of software and build systems
used across a variety of teams.
<dt>Notes<dd>
- Provenance may be incomplete and/or unsigned at L1. Higher levels require
more complete and trustworthy provenance.
</dl>
</section>
<section id="build-l2">
### Build L2: Build service
<dl class="as-table">
<dt>Summary<dd>
Forging the provenance or evading verification requires an explicit "attack",
though this may be easy to perform. Deters unsophisticated adversaries or those
who face legal or financial risk.
In practice, this means that builds run on a hosted service that generates and
signs[^sign] the provenance.
<dt>Intended for<dd>
Projects and organizations wanting to gain moderate security benefits of SLSA by
switching to a hosted build service, while waiting for changes to the build
service itself required by [Build L3].
<dt>Requirements<dd>
All of [Build L1], plus:
- The build runs on a hosted build service that generates and signs[^sign] the
provenance itself. This may be the original build, an after-the-fact
reproducible build, or some equivalent system that ensures the
trustworthiness of the provenance.
- Downstream verification of provenance includes validating the authenticity
of the provenance attestation.
<dt>Benefits<dd>
All of [Build L1], plus:
- Prevents tampering after the build through digital signatures[^sign].
- Deters adversaries who face legal or financial risk by evading security
controls, such as employees who face risk of getting fired.
- Reduces attack surface by limiting builds to specific build services that
can be audited and hardened.
- Allows large-scale migration of teams to supported build services early
while further hardening work ([Build L3]) is done in parallel.
</dl>
</section>
<section id="build-l3">
[^sign]: Alternate means of verifying the authenticity of the provenance are
also acceptable.
### Build L3: Hardened builds
<dl class="as-table">
<dt>Summary<dd>
Forging the provenance or evading verification requires exploiting a
vulnerability that is beyond the capabilities of most adversaries.
In practice, this means that builds run on a hardened build service that offers
strong tamper protection.
<dt>Intended for<dd>
Most software releases. Build L3 usually requires significant changes to
existing build services.
<dt>Requirements<dd>
All of [Build L2], plus:
- Build service implements strong controls to:
- prevent runs from influencing one another, even within the same project.
- prevent secret material used to sign the provenance from being
accessible to the user-defined build steps.
<dt>Benefits<dd>
All of [Build L2], plus:
- Prevents tampering during the build---by maintainers, compromised
credentials, or other tenants.
- Greatly reduces the impact of compromised package upload credentials by
requiring attacker to perform a difficult exploit of the build process.
- Provides strong confidence that the package was built from the official
source and build process.
</dl>
</section>
<!-- Link definitions -->
[build l0]: #build-l0
[build l1]: #build-l1
[build l2]: #build-l2
[build l3]: #build-l3
[future versions]: future-directions.md
[previous version]: ../v0.1/levels.md
[provenance attestation]: terminology.md