Commit a743d830 authored by Mark Lodato's avatar Mark Lodato
Browse files

Renumber levels to be integers.

That is:
- 1.5 => 2
- 2 => 3
- 3 => 4
parent 7fc63393
......@@ -54,11 +54,11 @@ wide range of tampering, confusion, and other supply chain attacks.
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
SLSA 4 is the end goal but may take many years and significant investment for
large organizations. SLSA 1 through SLSA 3 are stepping stones to recognize
meaningful progress.
What sets SLSA 3 apart from simple best practices is its resilience against
What sets SLSA 4 apart from simple best practices is its resilience against
determined adversaries. That is, SLSA is a **guarantee** that these practices
have been followed, though still not a guarantee that the software is "safe."
......@@ -81,7 +81,7 @@ chain risks and mitigations in a common language. This allows us to communicate
and act on those risks across organizational boundaries.
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
maker easily understands that SLSA 4 is better than SLSA 3 without understanding
any of the details. That said, we are not committed to numeric levels and are
open to other options.
......@@ -186,7 +186,7 @@ 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](#level-requirements) reproducible builds
For these reasons, SLSA 4 [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
......@@ -285,9 +285,8 @@ Special cases:
## SLSA definitions
_Reminder: The definitions below are not yet finalized and subject to change. In
particular, (1) we expect to renumber the levels to be integers; and (2) levels
2-3 are likely to undergo further changes._
_Reminder: The definitions below are not yet finalized and subject to change,
particularly SLSA 3-4._
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
......@@ -298,9 +297,9 @@ 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
There are four SLSA levels. SLSA 4 is the current highest level and represents
the ideal end state. SLSA 1–3 offer lower security guarantees but are easier to
meet. In our experience, achieving SLSA 4 can take many years and significant
effort, so intermediate milestones are important.
<table>
......@@ -312,15 +311,15 @@ effort, so intermediate milestones are important.
</thead>
<tbody>
<tr>
<td>SLSA 3
<td>SLSA 4
<td>"Auditable and Non-Unilateral." High confidence that (1) one can correctly and easily trace back to the original source code, its change history, and all dependencies and (2) no single person has the power to make a meaningful change to the software without review.
</tr>
<tr>
<td>SLSA 2
<td>SLSA 3
<td>"Auditable." Moderate confidence that one can trace back to the original source code and change history. However, trusted persons still have the ability to make unilateral changes, and the list of dependencies is likely incomplete.
</tr>
<tr>
<td>SLSA 1.5
<td>SLSA 2
<td>Stepping stone to higher levels. Moderate confidence that one can determine either who authorized the artifact or what systems produced the artifact. Protects against tampering after the build.
</tr>
<tr>
......@@ -335,7 +334,7 @@ effort, so intermediate milestones are important.
<table>
<thead>
<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>
<tr><th colspan="2">Requirement<th>SLSA 1<th>SLSA 2<th>SLSA 3<th>SLSA 4</tr>
</thead>
<tbody>
<tr><td rowspan="4">Source
......@@ -438,10 +437,10 @@ involved in the supply chain (source, build, distribution, etc.):
SLSA is not transitive. It describes the integrity protections of an artifact's
build process and top-level source, but nothing about the artifact's
dependencies. Dependencies have their own SLSA ratings, and it is possible for a
SLSA 3 artifact to be built from SLSA 0 dependencies.
SLSA 4 artifact to be built from SLSA 0 dependencies.
The reason for non-transitivity is to make the problem tractable. If SLSA 3
required dependencies to be SLSA 3, then reaching SLSA 3 would require starting
The reason for non-transitivity is to make the problem tractable. If SLSA 4
required dependencies to be SLSA 4, then reaching SLSA 4 would require starting
at the very beginning of the supply chain and working forward. This is
backwards, forcing us to work on the least risky component first and blocking
any progress further downstream. By making each artifact's SLSA rating
......@@ -457,7 +456,7 @@ security stance, as described in the [vision](#vision-case-study) below.
Let's consider how we might secure [curlimages/curl] from the
[motivating example](#motivating-example) using the SLSA framework.
### Incrementally reaching SLSA 3
### Incrementally reaching SLSA 4
Let's start by incrementally applying the SLSA principles to the final Docker
image.
......@@ -490,34 +489,34 @@ In the updated diagram, the provenance attestation says that the artifact
At SLSA 1, the provenance does not protect against tampering or forging but may
be useful for vulnerability management.
#### SLSA 1.5 and 2: Build service
#### SLSA 2 and 3: Build service
![slsa2](images/slsa-2.svg)
To reach SLSA 1.5 (and later SLSA 2), we must switch to a hosted build service
To reach SLSA 2 (and later SLSA 3), we must switch to a hosted build service
that generates provenance for us. This updated provenance should also include
dependencies on a best-effort basis. SLSA 2 additionally requires the source and
dependencies on a best-effort basis. SLSA 3 additionally requires the source and
build platforms to implement additional security controls, which might need to
be enabled.
In the updated diagram, the provenance now lists some dependencies, such as the
base image (`alpine:3.11.5`) and apk packages (e.g. `curl-dev`).
At SLSA 2, the provenance is significantly more trustworthy than before. Only
At SLSA 3, the provenance is significantly more trustworthy than before. Only
highly skilled adversaries are likely able to forge it.
#### SLSA 3: Hermeticity and two-person review
#### SLSA 4: Hermeticity and two-person review
![slsa3](images/slsa-3.svg)
![slsa4](images/slsa-4.svg)
SLSA 3 [requires](#level-requirements) two-party source control and hermetic
SLSA 4 [requires](#level-requirements) two-party source control and hermetic
builds. Hermeticity in particular guarantees that the dependencies are complete.
Once these controls are enabled, the Docker image will be SLSA 3.
In the updated diagram, the provenance now attests to its hermeticity and
includes the `cacert.pem` dependency, which was absent before.
At SLSA 3, we have high confidence that the provenance is complete and
At SLSA 4, we have high confidence that the provenance is complete and
trustworthy and that no single person can unilaterally change the top-level
source.
......@@ -549,7 +548,7 @@ node in our graph has its own, independent SLSA level. Just because an
artifact's level is N does not imply anything about its dependencies' levels.
In our example, suppose that the final [curlimages/curl] Docker image were SLSA
3 but its [curl-dev] dependency were SLSA 0. Then this would imply a significant
4 but its [curl-dev] dependency were SLSA 0. Then this would imply a significant
security risk: an adversary could potentially introduce malicious behavior into
the final image by modifying the source code found in the [curl-dev] package.
That said, even being able to _identify_ that it has a SLSA 0 dependency has
......
......@@ -8,7 +8,7 @@ This document enumerates all of the detailed requirements for a source to meet
A source **revision** is an immutable, coherent state of the source. In Git, for
example, a revision is a commit in the history reachable from a specific branch
in a specific repository. Different revisions within one repo MAY have different
levels. Example: the most recent revision on a branch meets SLSA 3 but very old
levels. Example: the most recent revision on a branch meets SLSA 4 but very old
historical revisions before the cutoff do not.
A source repository has a set of "trusted persons" who own the project and a
......@@ -23,9 +23,9 @@ Mozilla's mercurial hosting.
There are no source requirements at SLSA 1.
## SLSA 1.5
## SLSA 2
A revision meets SLSA 1.5 if all of the following are true:
A revision meets SLSA 2 if all of the following are true:
* **[Version Controlled]** Every change to the source is tracked in a version
control system that meets the following requriements.
......@@ -48,13 +48,13 @@ change history be made public. Rather, some organization must attest to the fact
that these requirements are met, and it is up to the consumer whether this
attestation is sufficient.
## SLSA 2
## SLSA 3
_NOTE: The SLSA 2 requirements are subject to change._
_NOTE: The SLSA 3 requirements are subject to change._
A revision meets SLSA 2 if all of the following are true:
A revision meets SLSA 3 if all of the following are true:
- The revision meets [SLSA 1.5](#slsa-15).
- The revision meets [SLSA 2](#slsa-2).
- **[Verified History]** Every change in the revision's history has at least
one strongly authenticated actor identities (author, uploader, reviewer,
......@@ -68,7 +68,7 @@ A revision meets SLSA 2 if all of the following are true:
parent history" is in scope. In other words, when a feature branch is
merged back into the main branch, only the merge itself is in scope.
- **[Historical Cutoff]** There is some TBD exception to allow existing
projects to meet SLSA 2/3 even if historical revisions were present in
projects to meet SLSA 3/4 even if historical revisions were present in
the history. Current thinking is that this could be either last N months
or a platform attestation guaranteeing that future changes in the next N
months will meet the requirements.
......@@ -88,13 +88,13 @@ A revision meets SLSA 2 if all of the following are true:
attestation is generated on 2021-01-01, the commit must be retained
until at least 2022-07-01.
## SLSA 3
## SLSA 4
_NOTE: The SLSA 3 requirements are subject to change._
_NOTE: The SLSA 4 requirements are subject to change._
A revision meets SLSA 3 if all of the following are true:
A revision meets SLSA 4 if all of the following are true:
- The revision meets [SLSA 2](#slsa-2).
- The revision meets [SLSA 3](#slsa-3).
- **[Two-Person Reviewed]** Every change in the revision's history was agreed
to by two trusted persons prior to submission, and both of these trusted
......
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