Introduction
In the last blog post, we talked about the SLSA terminology. Now it is time to focus on SLSA levels and tracks.
Within the SLSA framework, there are levels and tracks. Depending on them, it possible to incrementally harden and improve different areas of the supply chain. Tracks focus on individual sub-areas of the supply chain, for example on the build or provenance area. This helps to do the hardening independently of individual areas. The levels within the individual tracks indicate the quality of the hardening within the are. Each level defines requirements in order to reach the corresponding level. In practice, it is possible to be at level 3 in the build track, whereas only level 1 was reached in the source track. The levels are designed in such a way that the implementation costs increase with each level, so level one is basically easy to implement, whereas level 3 is difficult to achieve.
Currently, levels 0 to 3 and the build track are available. The lowest level 0 means that no requirements of the framework have been implemented. As already mentioned, each track defines different requirements for each level in order to be able to fulfill them. In the following we will focus on the build track.
The build track focuses on the provenance and validability of artifacts. It’s about defining how an artifact was built, who built the artifact, what process built the artifact, and what the artifact contains. This gives a consumer of software the certainty of whether the artifact they want to use is what it claims to be.
Levels
Level 1 focuses on documentation and error prevention. In this case, documentation means that the build process is documented by provenance data. This makes it easier to trace errors, for example if an incorrect source version was used. The SLSA framework specifies certain requirements for the build process and provenance data. The build process must be consistent. In addition, the provenance data, which contains information how the artifact was created, must be generated by the build platform. This data includes information about who created the artifact, what build process was used, and what dependencies and parameters were used in the build. It is also important that the provenance data is accessible to consumers of the artifact. This ensures transparency and trustworthiness because the origin and construction of the artifact are traceable. Since Level 1 is considered the start of the build track, it is easy for any company or development team to implement. Little or no changes to the workflow are required. The provenance data does not have to be complete or signed. At this level it is still possible to manipulate the provenance data.
- Build Level 2 focuses on ensuring that an artifact can no longer be manipulated after the build. Unlike Level 1, the software build at Level 2 must be carried out on a hosted build platform. This means that it cannot be carried out on a developer’s laptop, for example. In order to exclude manipulation of the artifact after the build, the provenance data is generated and signed by the build platform itself. The signature prevents manipulation and reduces the attack surface.
- The third level focuses on the build process itself to prevent manipulation during the build. This is mainly about hardening the build platform. The build platform must be architected in such a way that builds cannot influence each other. This includes, for example, that the key used to sign the provenance data is not accessible to the build scripts. Level 3 is the most complex to implement of the three levels, as entire workflows and system structures sometimes have to be restructured. However, risks are maximally reduced during the build, ensuring confidentiality, integrity and availability.
Tracks
After having described the importance of the individual levels, we will discuss the technical requirements that must be met in order to reach the corresponding level.
The Build Track divides the requirements into two parts. The first part of the requirements must be fulfilled by the producer and the second part contains requirements that are required to be fulfilled by the build system itself.
The producer can be anyone who is responsible for creating it and passing it on to third parties, for example entire organizations or a team of developers. The producer has three tasks. He is responsible for selecting the right build platform, defining the build process and distributing the provenance data.
To choose the right build platform, it is crucial that the build platform is capable of achieving the desired SLSA level.
SLSA version 1 requires the build process to be consistent. This makes it possible to provide the verifier with a clear understanding of how an artifact was created. Maintaining consistency in the build process makes it easier for others to assess the quality, reliability, and security of the artifact. Consistency in the build process creates expectations about how an artifact was built and how to ensure it meets the necessary standards. If a package is distributed through a package ecosystem that requires explicit metadata about the build process in the form of a configuration file, the producer must complete the configuration file and keep it up to date. This metadata can contain information about the artifact’s source code repository and build parameters.
The requirements for the build platform consist of two major requirementsments: the generation of provenance data and isolation.
Regarding provenance generation, SLSA defines 3 points, each of which correlates with the corresponding SLSA levels. To reach level 1, it is sufficient if this data exists, for level 2 the data must be authentic and for level 3 it must be unchangeable.
Level 1 defines that at the end of a build process there is provenance data about the build process and that this must be able to be uniquely identified by a cryptographic digest. The recommended format for provenance data should be SLSA provenance. Other formats can be used, but the other formats must have the same amount of information and should be bidirectionally translatable into SLSA Provenance.
To reach level 2, the provenance data must be generated by the build service’s control plain; unlike Level 1, where it didn’t matter who or what created the provenance data. In this case, however, there are two exceptions. The Subject field and fields marked as not necessary for Level 2 may be generated by a tenant of the build system. Provenance data must be authentic and the authenticity must be validatable. This is achieved by signing the provenance data. The provenance data is signed by a private key. The key may only be accessible to the build platform and not to the tenant.
At level 3 there are three requirements for the build system. The first requirement describes that cryptographic data such as the private key must be stored in a secure environment. For example, a Key Management System (KMS) must be used. The second requirement requires that the cryptographic data be isolated from the custom build steps. The third requirement describes that all fields in the provenance data were generated by the build system itself and that the custom build steps do not change the contents of this data.
SLSA’s requirement for the builds is that they run in isolation from each other so that there is no influence between the builds. Likewise, the build environment must be isolated from the control plane of the build system. Regarding isolation, SLSA has two requirements. For one thing, all steps of a build must take place on a hosted build platform and not, for example, on a developer’s laptop or computer. The implementation of the step is part of SLSA Level 2. On the other hand, all steps of a build must run in isolation from each other, so that there can be no external influences on the steps other than those previously defined as external parameters, and these must be included as such Provenance data must be recognizable. Isolation also includes the fact that one build cannot access cryptographic data of another build, such as signature keys. It must not be possible for two builds running in parallel to change the memory of another process. A short-lived environment must be provided for each build and when using a cache during the build, it must not be possible for a build to change it. Each run of a build must always produce the same result, whether a cache is used or not.
