-
Notifications
You must be signed in to change notification settings - Fork 213
/
levels.md
234 lines (159 loc) · 7.84 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
---
title: Security levels
description: 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 a descriptive overview of the SLSA levels and tracks, describing their intent.
---
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 a descriptive overview of the SLSA levels and tracks, describing
their intent. For the prescriptive requirements for each level, see
[Requirements](requirements.md). For a general overview of SLSA, see
[About SLSA](principles.md).
## 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 | Focus
| ----------- | ------------ | -----
| [Build L0] | (none) | (n/a)
| [Build L1] | Provenance showing how the package was built | Mistakes, documentation
| [Build L2] | Signed provenance, generated by a hosted build platform | Tampering after the build
| [Build L3] | Hardened build platform | Tampering during the build
<!-- For comparison: a future Build L4's focus might be reproducibility or
hermeticity or completeness of provenance -->
> 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 increasing levels of trustworthiness and
completeness in a package artifact's <dfn>provenance</dfn>. Provenance describes
what entity built the artifact, what process they used, and what the inputs
were. The lowest level only requires the provenance to exist, while higher
levels provide increasing protection against tampering of the build, the
provenance, or the artifact.
The primary purpose of the build track is to enable [verification] that the
artifact was built as expected. Consumers have some way of knowing what the
expected provenance should look like for a given package and then compare each
package artifact's actual provenance to those expectations. Doing so prevents
several classes of [supply chain threats](threats.md).
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 exists
<dl class="as-table">
<dt>Summary<dd>
Package has provenance showing how it was built. Can be used to prevent 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>
- Software producer follows a consistent build process so that others can form
expectations about what a "correct" build looks like.
- [Provenance] exists describing how the artifact was built, including the
build platform, build process, and top-level inputs.
- Software producer distributes provenance to consumers, preferably using a
convention determined by the package ecosystem.
<dt>Benefits<dd>
- Makes it easier for both producers and consumers to debug, patch, rebuild,
and/or analyze the software by knowing its precise source version and build
process.
- With [verification], 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 platforms
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: Hosted build platform
<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 platform 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 platform, while waiting for changes to the build
platform itself required by [Build L3].
<dt>Requirements<dd>
All of [Build L1], plus:
- Build platform runs on dedicated infrastructure, not an individual's
workstation, and the provenance is tied to that infrastructure through
a digital signature[^sign].
- Downstream verification of provenance includes validating the authenticity
of the provenance.
<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 platforms that
can be audited and hardened.
- Allows large-scale migration of teams to supported build platforms early
while further hardening work ([Build L3]) is done in parallel.
</dl>
</section>
<section id="build-l3">
[^sign]: Usually this means that the provenance is signed by a key that is only
accessible to the build platform, but 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 platform that offers
strong tamper protection.
<dt>Intended for<dd>
Most software releases. Build L3 usually requires significant changes to
existing build platforms.
<dt>Requirements<dd>
All of [Build L2], plus:
- Build platform 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 insider threats, 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]: terminology.md
[verification]: verifying-artifacts.md