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.
### Composition of SLSA levels
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.
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.
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.
### Accreditation and delegation
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.
<!-- Links -->
[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
<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.
## 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 ../README.md. -->
