This page covers all of the technical requirements for an artifact to meet the SLSA Levels.
Reminder: SLSA is in
alpha. The definitions below are not yet finalized and subject to change, particularly SLSA 3-4.
|Requirement||SLSA 1||SLSA 2||SLSA 3||SLSA 4|
|Source - Version controlled||✓||✓||✓|
|Source - Verified history||✓||✓|
|Source - Retained indefinitely||18 mo.||✓|
|Source - Two-person reviewed||✓|
|Build - Scripted build||✓||✓||✓||✓|
|Build - Build service||✓||✓||✓|
|Build - Build as code||✓||✓|
|Build - Ephemeral environment||✓||✓|
|Build - Isolated||✓||✓|
|Build - Parameterless||✓|
|Build - Hermetic||✓|
|Build - Reproducible||○|
|Provenance - Available||✓||✓||✓||✓|
|Provenance - Authenticated||✓||✓||✓|
|Provenance - Service generated||✓||✓||✓|
|Provenance - Non-falsifiable||✓||✓|
|Provenance - Dependencies complete||✓|
|Common - Security||✓|
|Common - Access||✓|
|Common - Superusers||✓|
○ = required unless there is a justification
See also Terminology for general SLSA concepts. The defintions below are only used in this document.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
Immutable reference: An identifier that is guaranteed to always point to the same, immutable artifact. This MUST allow the consumer to locate the artifact and SHOULD include a cryptographic hash of the artifact’s contents to ensure integrity. Examples: git URL + branch/tag/ref + commit ID; cloud storage bucket ID + SHA-256 hash; Subversion URL (no hash).
Provenance: Metadata about how an artifact was produced.
Revision: An immutable, coherent state of a 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 4 but very old historical revisions before the cutoff do not.
Strong authentication: Authentication that maps back to a specific person using an authentication mechanism which is resistant to account and credential compromise. For example, 2-factor authentication (2FA) where one factor is a hardware security key (i.e. YubiKey).
Trusted persons: Set of persons who are granted the authority to maintain a software project. For example, https://github.com/MarkLodato/dotfiles has just one trusted person (MarkLodato), while https://hg.mozilla.org/mozilla-central has a set of trusted persons with write access to the mozilla-central repository.
Every change to the source is tracked in a version control system that meets the following requirements:
Most popular version control system meet this requirement, such as git, Mercurial, Subversion, or Perforce.
NOTE: This does NOT require that the code, uploader/reviewer identities, or 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.
“○” = RECOMMENDED.
Every change in the revision’s history has at least one strongly authenticated actor identity (author, uploader, reviewer, etc.) and timestamp. It must be clear which identities were verified, and those identities must use two-step verification or similar. (Exceptions noted below.)
The revision and its change history are preserved indefinitely and cannot be deleted, except when subject to an established and transparent policy for obliteration, such as a legal or policy requirement.
Every change in the revision’s history was agreed to by two trusted persons prior to submission, and both of these trusted persons were strongly authenticated. (Exceptions from Verified History apply here as well.)
Requirements on build process:
All build steps were fully defined in some sort of “build script”. The only manual command, if any, was to invoke the build script.
All build steps ran using some build service, not on a developer’s workstation.
Examples: GitHub Actions, Google Cloud Build, Travis CI.
|Build as code||
The build definition and configuration executed by the build service is verifiably derived from text file definitions stored in a version control system.
Verifiably derived can mean either fetched directly through a trusted channel, or that the derived definition has some trustworthy provenance chain linking back to version control.
The build service ensured that the build steps ran in an ephemeral environment, such as a container or VM, provisioned solely for this build, and not reused from a prior build.
The build service ensured that the build steps ran in an isolated environment free of influence from other build instances, whether prior or concurrent.
The build output cannot be affected by user parameters other than the build entry point and the top-level source location. In other words, the build is fully defined through the build script and nothing else.
All transitive build steps, sources, and dependencies were fully declared up front with immutable references, and the build steps ran with no network access.
The user-defined build script:
The build service:
Re-running the build steps with identical input artifacts results in bit-for-bit identical output. Builds that cannot meet this MUST provide a justification why the build cannot be made reproducible.
“○” means that this requirement is “best effort”. The user-provided build script SHOULD declare whether the build is intended to be reproducible or a justification why not. The build service MAY blindly propagate this intent without verifying reproducibility. A consumer MAY reject the build if it does not reproduce.
Requirements on the process by which provenance is generated and consumed:
The provenance is available to the consumer in a format that the consumer accepts. The format SHOULD be in-toto SLSA Provenance, but another format MAY be used if both producer and consumer agree and it meets all the other requirements.
The provenance’s authenticity and integrity can be verified by the consumer. This SHOULD be through a digital signature from a private key accessible only to the service generating the provenance.
The data in the provenance MUST be obtained from the build service (either because the generator is the build service or because the provenance generator reads the data directly from the build service).
Regular users of the service MUST NOT be able to inject or alter the contents, except as noted below.
The following provenance fields MAY be generated by the user-controlled build steps:
Provenance cannot be falsified by the build service’s users.
NOTE: This requirement is a stricter version of Service Generated.
The following provenance fields MAY be generated by the user-controlled build steps without the build service verifying their correctness:
Provenance records all build dependencies that were available while running the build steps. This includes the initial state of the machine, VM, or container of the build worker.
Requirements on the contents of the provenance:
The provenance MUST identify the output artifact via at least one cryptographic hash. The provenance MAY provide multiple identifying cryptographic hashes using different algorithms. When only one hash is provided, the RECOMMENDED algorithm is SHA-256 for cross-system compatibility. If another algorithm is used, it SHOULD be resistant to collisions and second preimages.
The provenance identifies the entity that performed the build and generated the provenance. This represents the entity that the consumer must trust. Examples: “GitHub Actions with a GitHub-hosted worker”, “firstname.lastname@example.org’s machine”.
|Identifies build instructions||
The provenance identifies the top-level instructions used to execute the build.
The identified instructions SHOULD be at the highest level available to the build (e.g. if the build is told to run build.sh it should list build.sh and NOT the individual instructions in build.sh).
|Identifies source code||
The provenance identifies the repository origin(s) for the source code used in the build.
The identified repositories SHOULD only include source used directly in the build. The source of dependencies SHOULD NOT be included.
At level 2 this information MAY come from users and DOES NOT need to be authenticated by the builder.
At level 3+ this information MUST be authenticated by the builder (i.e. the builder either needs to have fetched the source itself or observed the fetch).
At level 4 this information MUST be complete (i.e. all source repositories used in the build are listed).
|✓||✓ (Authenticated)||✓ (Complete)|
|Identifies entry point||
The provenance identifies the “entry point” of the build definition (see build-as-code) used to drive the build including what source repo the configuration was read from.
|Includes all build parameters||
The provenance includes all build parameters under a user’s control. See Parameterless for details. (At L3, the parameters must be listed; at L4, they must be empty.)
|Includes all transitive dependencies||
The provenance includes all transitive dependencies listed in Dependencies Complete.
|Includes reproducible info||
The provenance includes a boolean indicating whether build is intended to be reproducible and, if so, all information necessary to reproduce the build. See Reproducible for more details.
The provenance includes metadata to aid debugging and investigations. This SHOULD at least include start and end timestamps and a unique identifier to allow finding detailed debug logs.
“○” = RECOMMENDED.
Common requirements for every trusted system involved in the supply chain (source, build, distribution, etc.)
The system meets some TBD baseline security standard to prevent compromise. (Patching, vulnerability scanning, user isolation, transport security, secure boot, machine identity, etc. Perhaps NIST 800-53 or a subset thereof.)
All physical and remote access must be rare, logged, and gated behind multi-party approval.
Only a small number of platform admins may override the guarantees listed here. Doing so MUST require approval of a second platform admin.