<td>Artifact that was directly authored or directly by persons, without modification. It is the beginning of the supply chain; we do not trace the provenance back any further.
<td>Git commit (source) hosted on GitHub (platform).
</tr>
<th>Build
<td>Process that transforms a set of input artifacts into a set of output artifacts. The inputs may be sources, dependencies, or ephemeral build outputs.
<td>.travis.yml (process) run by Travis CI (platform).
</tr>
<tr>
<th>Package
<td>Artifact that is "published" for use by others. In the model, it is
always the output of a build process, though that build process can be a
no-op.
<td>Docker image (package) distributed on DockerHub (platform).
</tr>
<tr>
<th>Dependency
<td>Artifact that is an input to a build process but that is not a source. In
the model, it is always a package.
<td>Alpine package (package) distributed on Alpine Linux (platform).
</tr>
</tbody>
</table>
Special cases:
* A ZIP file is containing source code is a package, not a source, because it
is built from some other source, such as a git commit.
## 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._
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
artifact meets this level, **provenance** is required. This serves as evidence
that the level's requirements have been met.
### Level descriptions
_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
effort, so intermediate milestones are important.
<table>
<thead>
<tr>
<th>Level
<th>Meaning
</tr>
</thead>
<tbody>
<tr>
<td>SLSA 3
<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>"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>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>
<td>SLSA 1
<td>Entry point into SLSA. Provenance indicates the artifact's origins without any integrity guarantees.
</tr>
</tbody>
</table>
### Level requirements
<!-- When editing this table, also edit spec/README.md. -->
<table>
<thead>
...
...
@@ -363,230 +97,44 @@ effort, so intermediate milestones are important.
</tbody>
</table>
_○ = required unless there is a justification_
Note: The actual requirements will necessarily be much more detailed and
nuanced. We only provide a brief summary here for clarity.
**[Source]** Requirements for the artifact's top-level source (i.e. the one
containing the build script):
***[Version Controlled]** Every change to the source is tracked in a version
control system that identifies who made the change, what the change was, and
when that change occurred.
***[Verified History]** The version control history indicates which actor
identities (author, uploader, reviewer, etc.) and timestamps were strongly
authenticated. For example, GitHub-generated merge commits for pull requests
meet this requirement.
***[Retained Indefinitely]** The artifact and its change history are retained
indefinitely and cannot be deleted.
***[Two-Person Review]** At least two trusted persons agreed to every change
in the history.
**[Build]** Requirements for the artifact's build process:
***[Scripted]** All build steps were fully defined in some sort of "build
script". The only manual command, if any, was to invoke the build script.
***[Build Service]** All build steps ran using some build service, such as a
Continuous Integration (CI) platform, not on a developer's workstation.
***[Ephemeral Environment]** The build steps ran in an ephemeral environment,
such as a container or VM, provisioned solely for this build, and not reused
by other builds.
***[Isolated]** The build steps ran in an isolated environment free of
influence from other build instances, whether prior or concurrent. Build
caches, if used, are purely content-addressable to prevent tampering.
***[Hermetic]** All build steps, sources, and dependencies were fully
declared up front with immutable references, and the build steps ran with no
network access. All dependencies were fetched by the build service control
plane and checked for integrity.
***[Reproducible]** 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.)
**[Provenance]** Requirements for the artifact's provenance:
***[Available]** Provenance is available to the consumer of the artifact, or
to whomever is verifying the policy, and it identifies at least the
artifact, the system that performed the build, and the top-level source. All
artifact references are immutable, such as via a cryptographic hash.
***[Authenticated]** Provenance's authenticity and integrity can be verified,
such as through a digital signature.
***[Service Generated]** Provenance is generated by the build service itself,
as opposed to user-provided tooling running on top of the service.
***[Non-Falsifiable]** Provenance cannot be falsified by the build service's
users.
***[Dependencies Complete]** Provenance records all build dependencies,
meaning every artifact that was available to the build script. This includes
the initial state of the machine, VM, or container of the build worker.
**[Common]** Common requirements for every trusted system involved in the supply
chain (source, build, distribution, etc.):
***[Security]** The system meets some TBD baseline security standard to
prevent compromise. (Patching, vulnerability scanning, user isolation,
transport security, secure boot, machine identity, etc. Perhaps
In reality, the graph is intractably large due to the fanout of dependencies.
There will need to be some way to trim the graph to focus on the most important
components. While this can reasonably be done by hand, we do not yet have a
solid vision for how best to do this in an scalable, generic, automated way. One
idea is to use ecosystem-specific heuristics. For example, Debian packages are
built and organized in a very uniform way, which may allow Debian-specific
heuristics.
SLSA addresses three issues:
### Composition of SLSA levels
* Software producers want to secure their supply chains but don't know exactly
how.
* Software consumers want to understand and limit their exposure to supply
chain attacks but have no means of doing so.
* Artifact signatures alone only prevent a subset of the attacks we care
about.
An artifact's SLSA level is not transitive, so some aggregate measure of
security risk across the whole supply chain is necessary. In other words, each
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.
At a minimum, SLSA can be used as a set of guiding principles for software
producers and consumers. More importantly, SLSA allows us to talk about supply
chain risks and mitigations in a common language. This allows us to communicate
and act on those risks across organizational boundaries.
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
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
tremendous value because it can help focus efforts.
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
any of the details. That said, we are not committed to numeric levels and are
open to other options.
Formation of this aggregate risk measure is left for future work. It is perhaps
too early to develop such a measure without real-world data. Once SLSA becomes
more widely adopted, we expect patterns to emerge and the task to get a bit
easier.
Once SLSA is complete it will provide a mapping from requirements that the
supply chain can implement to the attacks they can prevent. Software producers
and consumers will be able to look at the SLSA level of a software artifact and
know what attacks have been defended against in its production.
### Accreditation and delegation
## How to get started
Accreditation and delegation will play a large role in the SLSA framework. It is
not practical for every software consumer to fully vet every platform and fully
walk the entire graph of every artifact. Auditors and/or accreditation bodies
can verify and assert that a platform or vendor meets the SLSA requirements when
configured in a certain way. Similarly, there may be some way to "trust" an
artifact without analyzing its dependencies. This may be particularly valuable
for closed source software.
**Developers:** For instructions on how to produce and verify SLSA-compliant
software... **\[TODO]**.
## Next steps
**Implementers:** For detailed requirements on how source and build systems can
meet SLSA, see [spec/README.md].
We welcome all comments and suggestions for this document via GitHub issues,
pull requests, [email][mailing list], or [feedback form]. Join the
[mailing list] to follow the discussion and progress.
Issues that we must work out:
* Agree on the principles, terminology, and high-level strategy.
* Define a threat model describing specific threats we intend to address.
* Specify detailed requirements for Source, Build, Provenance, and Common to
meet those principles.
* Agree on a leveling system.
* Document more end-to-end examples to show real threats and mitigations.
* Examples showing how to use common platforms to achieve SLSA (or an
approximation) today.
## Related work
In parallel to the SLSA specification, there is work to develop core formats and
...
...
@@ -638,7 +186,6 @@ Other takes on provenance and CI/CD:
[Binary Authorization for Borg]:https://cloud.google.com/security/binary-authorization-for-borg
[Threats, Risks, and Mitigations in the Open Source Ecosystem]:https://github.com/Open-Source-Security-Coalition/Open-Source-Security-Coalition/blob/master/publications/threats-risks-mitigations/v1.1/Threats%2C%20Risks%2C%20and%20Mitigations%20in%20the%20Open%20Source%20Ecosystem%20-%20v1.1.pdf
