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
diff --git a/images/slsa-3.svg b/images/slsa-4.svg
similarity index 100%
rename from images/slsa-3.svg
rename to images/slsa-4.svg
diff --git a/source-requirements.md b/source-requirements.md
index d3696bcad..9bcaa5b4d 100644
--- a/source-requirements.md
+++ b/source-requirements.md
@@ -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
|