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. ...@@ -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 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. 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 SLSA 4 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 large organizations. SLSA 1 through SLSA 3 are stepping stones to recognize
meaningful progress. 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 determined adversaries. That is, SLSA is a **guarantee** that these practices
have been followed, though still not a guarantee that the software is "safe." 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 ...@@ -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. and act on those risks across organizational boundaries.
Numeric levels, in particular, are useful because they are simple. A decision 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 any of the details. That said, we are not committed to numeric levels and are
open to other options. open to other options.
...@@ -186,7 +186,7 @@ bit-for-bit identical output. This property ...@@ -186,7 +186,7 @@ bit-for-bit identical output. This property
including easier debugging, more confident cherry-pick releases, better build including easier debugging, more confident cherry-pick releases, better build
caching and storage efficiency, and accurate dependency tracking. 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. 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) [Example](https://lists.reproducible-builds.org/pipermail/rb-general/2021-January/002177.html)
justifications include profile-guided optimizations or code signing that justifications include profile-guided optimizations or code signing that
...@@ -285,9 +285,8 @@ Special cases: ...@@ -285,9 +285,8 @@ Special cases:
## SLSA definitions ## SLSA definitions
_Reminder: The definitions below are not yet finalized and subject to change. In _Reminder: The definitions below are not yet finalized and subject to change,
particular, (1) we expect to renumber the levels to be integers; and (2) levels particularly SLSA 3-4._
2-3 are likely to undergo further changes._
An artifact's **SLSA level** describes the integrity strength of its direct 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 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. ...@@ -298,9 +297,9 @@ that the level's requirements have been met.
_This section is non-normative._ _This section is non-normative._
There are four SLSA levels. SLSA 3 is the current highest level and represents There are four SLSA levels. SLSA 4 is the current highest level and represents
the ideal end state. SLSA 1–2 offer lower security guarantees but are easier to the ideal end state. SLSA 1–3 offer lower security guarantees but are easier to
meet. In our experience, achieving SLSA 3 can take many years and significant meet. In our experience, achieving SLSA 4 can take many years and significant
effort, so intermediate milestones are important. effort, so intermediate milestones are important.
<table> <table>
...@@ -312,15 +311,15 @@ effort, so intermediate milestones are important. ...@@ -312,15 +311,15 @@ effort, so intermediate milestones are important.
</thead> </thead>
<tbody> <tbody>
<tr> <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. <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>
<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. <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>
<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. <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>
<tr> <tr>
...@@ -335,7 +334,7 @@ effort, so intermediate milestones are important. ...@@ -335,7 +334,7 @@ effort, so intermediate milestones are important.
<table> <table>
<thead> <thead>
<tr><th colspan="2"> <th colspan="4">Required at</tr> <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> </thead>
<tbody> <tbody>
<tr><td rowspan="4">Source <tr><td rowspan="4">Source
...@@ -438,10 +437,10 @@ involved in the supply chain (source, build, distribution, etc.): ...@@ -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 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 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 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 The reason for non-transitivity is to make the problem tractable. If SLSA 4
required dependencies to be SLSA 3, then reaching SLSA 3 would require starting 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 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 backwards, forcing us to work on the least risky component first and blocking
any progress further downstream. By making each artifact's SLSA rating 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. ...@@ -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 Let's consider how we might secure [curlimages/curl] from the
[motivating example](#motivating-example) using the SLSA framework. [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 Let's start by incrementally applying the SLSA principles to the final Docker
image. image.
...@@ -490,34 +489,34 @@ In the updated diagram, the provenance attestation says that the artifact ...@@ -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 At SLSA 1, the provenance does not protect against tampering or forging but may
be useful for vulnerability management. be useful for vulnerability management.
#### SLSA 1.5 and 2: Build service #### SLSA 2 and 3: Build service
![slsa2](images/slsa-2.svg) ![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 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 build platforms to implement additional security controls, which might need to
be enabled. be enabled.
In the updated diagram, the provenance now lists some dependencies, such as the 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`). 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. 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. builds. Hermeticity in particular guarantees that the dependencies are complete.
Once these controls are enabled, the Docker image will be SLSA 3. Once these controls are enabled, the Docker image will be SLSA 3.
In the updated diagram, the provenance now attests to its hermeticity and In the updated diagram, the provenance now attests to its hermeticity and
includes the `cacert.pem` dependency, which was absent before. 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 trustworthy and that no single person can unilaterally change the top-level
source. source.
...@@ -549,7 +548,7 @@ node in our graph has its own, independent SLSA level. Just because an ...@@ -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. 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 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 security risk: an adversary could potentially introduce malicious behavior into
the final image by modifying the source code found in the [curl-dev] package. 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 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 ...@@ -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 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 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 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. historical revisions before the cutoff do not.
A source repository has a set of "trusted persons" who own the project and a A source repository has a set of "trusted persons" who own the project and a
...@@ -23,9 +23,9 @@ Mozilla's mercurial hosting. ...@@ -23,9 +23,9 @@ Mozilla's mercurial hosting.
There are no source requirements at SLSA 1. 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 * **[Version Controlled]** Every change to the source is tracked in a version
control system that meets the following requriements. control system that meets the following requriements.
...@@ -48,13 +48,13 @@ change history be made public. Rather, some organization must attest to the fact ...@@ -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 that these requirements are met, and it is up to the consumer whether this
attestation is sufficient. 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 - **[Verified History]** Every change in the revision's history has at least
one strongly authenticated actor identities (author, uploader, reviewer, one strongly authenticated actor identities (author, uploader, reviewer,
...@@ -68,7 +68,7 @@ A revision meets SLSA 2 if all of the following are true: ...@@ -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 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. merged back into the main branch, only the merge itself is in scope.
- **[Historical Cutoff]** There is some TBD exception to allow existing - **[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 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 or a platform attestation guaranteeing that future changes in the next N
months will meet the requirements. months will meet the requirements.
...@@ -88,13 +88,13 @@ A revision meets SLSA 2 if all of the following are true: ...@@ -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 attestation is generated on 2021-01-01, the commit must be retained
until at least 2022-07-01. 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 - **[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 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