The SLSA Framework
In the last blog, we showed different frameworks for supply chains including the Secure Software Development Framework (SDDF), In-toto Attestation Framework and Supply Chain Level for Software Artefacts. We also addressed tools including Notary and Sigstore (with Cosign, Fulcio and Rekor).
In the following blog post, we will set the foundations for the SLSA framework. We begin with a definition and terminologies. SLSA is a framework that helps to secure a software supply chain. It gives software developers a guide on how to secure development and provides consumers with the information about the security of software artefacts. This includes a domain specific language, the possibility to evaluate the trustworthiness of artifacts, and a checklist of requirements in order to comply with the SSDF.
Finally, I also want to mention the areas in which SLSA is not used.
SLSA does not guarantee whether the code written for the artifacts has followed secure coding practices. In addition, it does not protect against companies that deliberately incorporate malware into their software. However, it can minimize the risk of an introducing vulnerabilities from internal sources. It’s also worth noting that the SLSA level, by design, is not transitive. A level describes the integrity protections of an artifact’s build process and top-level source but nothing about the artifact’s dependencies. It means that each artifact’s SLSA rating is independent of its dependencies The reason for this is that the development of software would be slowed down too much because one would have to pay attention and wait until a dependency meets the same standards as the artifact for which it is used.
Roles
SLSA defines several roles within in a software supply chain. A person or an organization can have multiple roles. A role can also be used by several people or companies.
The role of the producer is the one or organization that makes software available for others to consume. The role of the consumer describes who uses or consumes the producer’s software. A producer can also be a consumer at the same time, since, for example, he uses libraries or frameworks from others for his software. The third role is the verifier. He checks the authenticity of an artifact. The fourth and final role is the infrastructure provider, which provides software and services to other roles. These can be, for example, package registries or build platforms.
Build Model
- A tenant invokes the build by specifying external parameters through an interface, either directly or via some trigger. Usually, at least one of these external parameters is a reference to a dependency. (External parameters are literal values while dependencies are artifacts.)
- The build platform’s control plane interprets these external parameters, fetches an initial set of dependencies, initializes a build environment, and then starts the execution within that environment.
- The build then performs arbitrary steps, which might include fetching additional dependencies, and then produces one or more output artifacts. The steps within the build environment are under the tenant’s control. The build platform isolates build environments from one another to some degree (which is measured by the SLSA Build Level).
Package Model
After an artifact has been created, it is necessary to distribute it -in the form of packages. A package is an identifiable software unit that is intended for distribution. The term “package” can refer to both the artifact itself and the associated package name. An artifact is an immutable object, such as a file, while the package name is the name of a changeable collection of objects. All artifacts in a collection represent the same software but in different versions, with the name being ecosystem specific. The term “package ecosystem” describes a set of rules and conventions that determine how packages are distributed and how clients can resolve a package name into one or more specific artifacts. This is where a package manager client comes into play, a client-side tool used to interact with a package ecosystem. Finally, the package registry is responsible for mapping package names to artifacts. A single ecosystem can support multiple registries to ensure the efficient management and distribution of software packages.
For containers, the package ecosystem can be the Open Container Initiative (OCI), which aims to establish standards for containers and container platforms. Within OCI a package in relation to OCI is called a blob, the package name is called a repository and the artifact is called a blob. To reference a specific immutable blob, the reference is composed of repository, blob and digest.
Verification Models
After artifacts have been built and a suitable way to distribute artifacts has been found, a way must be found to verify the artifacts and the build platform on which they were built. The SLSA framework suggests that the operator of the build platform certifies the build platform within regular intervals and makes the certification available to consumers. Furthermore, artifacts are checked regularly. Expectations are a set of constraints on the package’s lineage metadata. Provenance verification involves checking the artifacts from the package ecosystem to ensure that the package’s expectations are met before the package is used. During Build platform verification, build platforms are certified for their compliance with SLSA requirements at the specified level.
