Part 5: Supply Chain – SLSA Attestation

Table of Contents:

Tags:

Introduction

After having explained the basics of the SLSA framework, we want to give some insights into SLSA attestations now.

What is an attestation? An attestation is a way to generate authenticated metadata about an artifact. This makes it possible for a consumer of software to find out how it was built, who built it and which build system it was built with. Attestations also provide the option of having metadata verified by a policy engine, such as in-toto or binary authorization. For this purpose, the SLSA framework offers the slsa-verifier, which verifies the SLSA provenance format.


General Model

The SLSA framework defines a general model according to which an attestation should be built.

The model defined by the SLSA framework consists of four main components, namely the bundle, the envelope, the statement and the predicate. The outer-right component of the model is the bundle, which describes a bundle of several attestations. Different attestations at different points in the software supply chain can be bundled in one place. These include, for example, vulnerability scans, the build process and the artifact. Combining the attestations in a bundle makes it easier for the software consumer to make well-founded decisions.

The actual attestation of an artifact is located within the envelope, which in turn consists of two components: The signature and the message. The signature contains information about the issuer of the attestation and the message contains further information. The third component is the statement. The statement binds the attestation to a specific artifact and must contain at least one subject and one predicate. The subject indicates which artifacts the predicate applies to. The Predicate is the innermost part of an attestation and contains information about the subject. The SLSA framework does not contain precise definitions regarding the scope of information that can be included in an attestation. However, links are suggested. The links serve to represent a hypergraph. In this hypergraph, the artifacts are represented as nodes and the attestations as hyperedges. The links are intended to enable predicate-agnostic processing of the graph.

Furthermore, the SLSA framework defines that there should be a central storage in which the attestations are stored and retrieved and can be viewed by a consumer.

Provenance

The Provenance Predicate provides verifiable information about a software artifact and precisely explains the place of origin, the date of origin and the creation process of the artifact. This guarantee gives the user of a software the confidence that the artifact meets expectations and can be reproduced independently if necessary.

Verification Summary Attestation (VSA)

The VSA describes at which SLSA level an artifact or group of artifacts was verified and other details about the verification process, including the SLSA level at which the dependencies were verified. This makes it easier to decide whether to use an artifact. This means that a consumer does not have to include all attestations of an artifact and the attestations of their dependencies in the decision-making process. It also allows software producers to keep details of their build process confidential while still being able to communicate that certain verifications have been carried out. The model is based on the existence of a verifier, which has a position of trust with the consumer. The verifier verifies the artifact and the associated attestations against a policy and then generates the VSA.

Autor

Denny Fehler

Consultant

Dr. Guido Söldner

Geschäftsführer

Guido Söldner ist Geschäftsführer und Principal Consultant bei Söldner Consult. Sein Themenfeld umfasst Cloud Infrastruktur, Automatisierung und DevOps, Kubernetes, Machine Learning und Enterprise Programmierung mit Spring.