Commit 5310e40a authored by Mark Lodato's avatar Mark Lodato
Browse files

Add Reproducibility as a recommendation for SLSA 3.

At SLSA 3, we now recommend reproducible builds. This is not a strict
requirement because not all builds can become reproducible, as explained
in the text. Once we write the detailed requirements, we will likely
want to somehow explain that reproducible should be the default, while
still allowing individual projects to opt-out.

The reason for adding this recommendation is to move the industry
towards reproducibility, which is a generally useful property. By having
it as the "default" path, most software will just go with the past of
least resistance rather than opting out.

Note that this does not require *verifying* the reproduction for
security. Instead, the builder just claims that it was reproducible,
presumably by building it twice and making sure that the output is
parent 684bbf7c
......@@ -184,10 +184,8 @@ more, see [Threats, Risks, and Mitigations in the Open Source Ecosystem].
including easier debugging, more confident cherry-pick releases, better build
caching and storage efficiency, and accurate dependency tracking. Most builds
ought to be reproducible, but they often are not simply because it is not the
default mode of operation by build tools. We strongly support any effort to make
reproducibility the default mode of operation and the norm in the industry.
caching and storage efficiency, and accurate dependency tracking. For these
reasons, we recommend reproducibility and require hermeticity at SLSA 3.
In terms of security, _verified_ reproducible builds are often
......@@ -219,7 +217,7 @@ chain integrity, nor are they practical in all cases:
many cases, or develop multiple, independent in-house rebuilders, which is
likely prohibitively expensive.
For these reasons, we do not require reproducible builds as part of SLSA.
For these reasons, we do not _require_ reproducible builds as part of SLSA.
Instead, it is best to think of verified reproducible builds as one option for
implementing some of the SLSA requirements.
......@@ -329,9 +327,10 @@ Each SLSA level has a set of requirements.
<tr> <td>Retention <td> <td>18 mo.<td>indef </tr>
<tr> <td>Change History <td> <td><td></tr>
<tr> <td>Two-Person Review<td> <td> <td></tr>
<tr><td rowspan="5">Build <td>Automation <td><td><td></tr>
<tr><td rowspan="6">Build <td>Automation <td><td><td></tr>
<tr> <td>Isolation <td> <td><td></tr>
<tr> <td>Hermeticity <td> <td> <td></tr>
<tr> <td>Reproducibility <td> <td> <td></tr>
<tr> <td>Source Integrity <td> <td>* <td></tr>
<tr> <td>Provenance <td><td>* <td></tr>
<tr><td rowspan="4">Deploy<td>Provenance Chain <td><td><td></tr>
......@@ -347,6 +346,7 @@ Each SLSA level has a set of requirements.
* ✓ = required at this level
* ○ = recommended at this level, but not strictly required
*\* = required at this level, but best effort because it depends on
hermeticity, which is not required at this level
* † = detection is allowed instead of prevention
......@@ -375,6 +375,9 @@ nuanced. We only provide a brief summary here for clarity.
influence from other build instances, whether prior or concurrent.
* **[Hermeticity]** All build steps, sources, and dependencies were fully
declared up front and the build steps ran with no network access.
* **[Reproducibility]** Re-running the build steps with identical input
artifacts results in bit-for-bit identical output. (Strongly recommended but
not required.)
* **[Source Integrity]** All input artifacts were fetched in a manner that
prevents tampering, such as TLS.
* **[Provenance]** Signed provenance recorded the input artifacts, output
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment