documentation.suse.com / SLSA: Securing the Software Supply Chain
Documentation survey

SLSA: Securing the Software Supply Chain

SUSE Best Practices

Security

Authors
Marcus Meissner, Distinguished Engineer Solutions Security (SUSE)
Jana Jaeger, Project Manager Technical Documentation (SUSE)
SUSE logo
All SUSE Products
Date: 2022-06-02

This document details how SUSE, as a long-time champion and expert of software supply chain security, prepares for SLSA L4 compliance.

Disclaimer: This document is part of the SUSE Best Practices series. All documents published in this series were contributed voluntarily by SUSE employees and by third parties. If not stated otherwise inside the document, the articles are intended only to be one example of how a particular action could be taken. Also, SUSE cannot verify either that the actions described in the articles do what they claim to do or that they do not have unintended consequences. All information found in this document has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Therefore, we need to specifically state that neither SUSE LLC, its affiliates, the authors, nor the translators may be held liable for possible errors or the consequences thereof.

1 Software supply chain security at SUSE

Securing our software supply chain is a top priority for SUSE to protect our customers from security risks, known and zero-day vulnerabilities. Ensuring that no threat actor can inject malicious code into our build service systems is attested by industry-leading security certifications. Our teams continually work to certify all SUSE products, and develop security solutions to offer our customers the highest level of trust and reliability.

A new industry standardization effort named SLSA (Supply chain Levels for Software Artifacts), started by Google and driven by several industry stakeholders, aims to protect the integrity of the software supply chain.

SLSA defines four levels of assurance, going from basic requirements at level 1 to strict rules and documentation requirements at level 4.

While the SLSA standard is still in development, SUSE already considers it as a great representation of needs for a secure product build environment, and we are adjusting our processes and tooling to meet the requirements of the highest assurance level 4.

2 Background: Threats to the supply chain and their mitigation

The software supply chain contains several known points of attack. They are illustrated by the graphic below. For an exhaustive list of threats and their mitigation, refer to https://slsa.dev/spec/v0.1/threats.

Software supply chain and possible threats
Figure 1: Software supply chain and possible threats
Source threats

Typical source code threats include bad code that introduces vulnerabilities or a compromised source control system. To address bad code injection, SLSA mandates two-person reviews. To prevent source code from getting compromised, SLSA mandates strong measures to secure the source control systems.

Build threats

Build threats include code commits to the build that were not tracked by the source control system, a compromised build platform, bypassing the CI/CD system, a compromised package repository, and injecting bad packages. Most build threats are mitigated by maintaining a controlled build environment, where each build is also fully encapsulated on its own, not influenceable from outside, or even reproducible. To prove this to the outside, detailed provenance data can be generated, which allows for the external inspection of the builds. Strong security controls ensure that the build platform is not easily compromised.

Dependency threats

Dependency threats come into play where risky dependencies are used. SLSA addresses this kind of threat by mandating provenance for all artifacts (files, git commits, directories of files, container images, ...), so one would have an indication that this dependency was not built from the proper builder or out of the designated GitHub repository.

3 SLSA components

SLSA is designed to standardize the four key components of a software supply chain. Learn about these components, the respective SLSA requirements, and whether and how SUSE's build process meets these requirements today.

For a complete summary of SLSA requirements, refer to the official SLSA project pages: https://slsa.dev/spec/v0.1/requirements.

Note
Note: Reading the requirement tables

To understand the SLSA requirement tables, check the following legend:

Yes
No
Best effort

3.1 Source code management

Keeping source code integrity is the key aspect of supply chain integrity. Source code integrity needs to be defended against all threats originating from insider or outsider attacks.

SLSA mandates the following criteria to be met to ensure source code integrity:

Table 1: SLSA4 Source requirements and SUSE's OBS
Requirement Required at SLSA4 Met by OBS/SUSE
Version-controlled
Verified history
Retained indefinitely
Two-person reviewed

See how SUSE's current software building pipeline that uses the Open Build Service (OBS) meets the above requirements:

Version-controlled source
  • SLSA L4 requirement.  Changes to the source must be tracked in a version control system which, in turn, needs to provide a change history that contains both the identities of the uploader and the reviewers, time stamps of the reviews/submissions, a comprehensive description of the change, its content, and parent reviews. The version control system must also provide an immutable reference to each revision. This requirement is met by most current version control systems, for example, git.

  • SUSE's processes.  OBS meets this requirement as it assigns numeric identifiers to commits. The commit stores information about the author, the commit time, a comment describing the commit, and other information. The commit also contains an identification of the source content, like the tree object in git. OBS uses an MD5 sum for identification purposes, but also makes sure that there is no collision with other source content.

Verified revision history
  • SLSA L4 requirement.  The history of a revision must be verifiable, that is, it must contain a time stamp and carry at least one strongly authenticated actor identity. Actors in this context are the author, submitter, or reviewer of the revision. Identities themselves must be verifiable and use a two-step verification process, or something similar.

  • SUSE's processes.  Each commit stores information about the author and commit time. It also contains a comment describing the commit and other information. Identities of all actors are verifiable and use two-factor authentication.

Revision and change history are retained indefinitely
  • SLSA L4 requirement.  The revision and its change history must be preserved indefinitely and cannot be deleted. Exceptions can be made if there is a legal or policy requirement that mandates the obliteration of this revision/change history.

  • SUSE's processes.  SUSE retains all sources, but also any shipped binary indefinitely. A retraction of a shipped update from the customer's channels does not lead to its removal from the build system. Furthermore, all source references and binary shipments including bug tracker references (CVE, bugzilla) are tracked by the build system for each shipment channel.

Two-person reviewed
  • SLSA L4 requirement.  Two trusted persons (see above) need to agree to every change in the revision history before it is submitted. Both of them must be strongly authenticated.

  • SUSE's processes.  The workflows for creating a new product and delivering maintenance updates involve multiple parties, like the core code review team and the maintenance or product release managers as a minimum. Furthermore, there are reviews by subject matter experts and additional checks for quality assurance and legal aspects. These reviews are enforced by the OBS, and a single decline rejects the entire release process.

3.2 Building and build system

The next part of the integrity chain is the actual build process that turns sources to binaries. The entire build process must be secured against any kind of unknown or outside influence to avoid possible tampering with the builds. Builds must be reproducible to allow verification and checking of build results.

Table 2: SLSA4 Build (process) requirements and SUSE's OBS
Requirement Required at SLSA4 Achieved
Scripted build
Build service
Build as code
Ephemeral environment
Isolated
Parameterless
Hermetic
Reproducible

See how SUSE's current software building pipeline with the Open Build Service (OBS) meets the above requirements:

Scripted build
  • SLSA L4 requirement.  Define all build steps in any kind of build script. Manual interaction is limited to invoking the build script itself.

  • SUSE's processes.  This is achieved by the SUSE build script also used by the OBS. Even the decision to invoke a build is made by OBS based on the submitted code changes or other builds.

Build service
  • SLSA L4 requirement.  Some build service runs the build steps. Running builds on developers' workstations does not qualify as a build service.

  • SUSE's processes.  Met by OBS (runs in a build cluster in the SUSE data center).

Build as code
  • SLSA L4 requirement.  Store the build definition and configuration in text files and keep them under version control. They must be executed by the build service.

  • SUSE's processes.  The recipe files defining the build process are part of the sources of the individual packages, for example the RPM spec file, its sources and patches, or image and container description files. The build environment configuration (project config) is also under source control in OBS.

Ephemeral environment
  • SLSA L4 requirement.  Build steps are run in an ephemeral environment such as a VM or container. These environments must not be recycled from a prior build and must be provisioned solely for this build.

  • SUSE's processes.  Met by OBS by using an isolated KVM instance for each build. Access to the outside is not possible (no network), only the sources and binaries prepared by OBS can be used. OBS also decides which pieces of the build artifacts are used. This includes running Linux kernel in the VM.

Isolated
  • SLSA L4 requirement.  Build steps must be run isolated from each other. No build instance, either prior or concurrent, may influence others.

  • SUSE's processes.  Met by OBS (builds in KVM).

Parameterless
  • SLSA L4 requirement.  The build is fully and solely defined through the build script and nothing else. Builds cannot be affected by any user input/parameters (except for build entry point and top-level source location).

  • SUSE's processes.  The build happens completely decoupled from any user interaction. Any parameter must be part of any source submission. No input is possible during the build, which is ensured by the KVM setup. The only output during the build is the build log.

Hermetic
  • SLSA L4 requirement.  All build steps must be shielded from any kind of external or internal influences. All transitive build steps, sources and dependencies are declared up front with immutable references and run without network access.

  • SUSE's processes.  Met by OBS (builds in a KVM guest without network, and everything required for the build is injected before the build instance is brought up).

Reproducible
  • SLSA L4 requirement.  When a build is rerun with identical input, it must yield identical results (bit-for-bit). Builds that cannot meet this requirement must provide a justification why they cannot be made reproducible. This requirement is best effort.

  • SUSE's processes.  The OBS build system tracks all used binaries for each build and can reproduce the build environment of any released binary. The binaries used are also referenced in in-toto provenance files and made available together with the sources starting from SUSE Linux Enterprise 15 SP4 builds. Older builds may have missing binaries because of the nature of the bootstrapping process. It is notable that the SUSE Linux Enterprise 15 code base is not enforcing binary identical reproducibility yet. Instead, builds are compared and known good differences are accepted (for example time stamps or build host name). This validation is done by the code in the build-compare package.

3.3 Provenance

A key aspect of supply chain security is the ability to prove that a build has been completed / a package built according to all SLSA4-mandated requirements. This provenance is established by means of providing metadata that proves compliance to SLSA.

The SLSA requirements for provenance can be grouped into:

  • process requirements on provenance generation and consumption

  • requirements on the contents of the provenance

For provenance generation and consumption, SLSA mandates the following requirements:

Table 3: SLSA4 Build provenance process requirements and SUSE's OBS
Requirement Required at SLSA4 Achieved
Available
Authenticated
Service-generated
Non-falsifiable
Dependencies complete

Learn how SUSE's OBS meets the SLSA4 provenance process requirements:

Available
  • SLSA L4 requirement.  Provide provenance in a format that is accepted by the consumer.

  • SUSE's processes.  Provided by SUSE.

Authenticated
  • SLSA L4 requirement.  Consumer can verify the authenticity and integrity of the provenance.

  • SUSE's processes.  The provenance records are signed by OBS after the build.

Service-generated
  • SLSA L4 requirement.  Provenance data must be provided by the build service.

  • SUSE's processes.  The build service creates the provenance file.

Non-falsifiable
  • SLSA L4 requirement.  Build service users cannot falsify provenance.

  • SUSE's processes.  Signing is done outside of the build in the build service and cannot be influenced by the user.

Dependencies complete
  • SLSA L4 requirement.  Record all build dependencies that were available at the build time (includes initial state of container, VM, build worker or machine).

  • SUSE's processes.  The component downloading the build environment generates the dependency part of the provenance file. Nothing else is available for the build process.

For provenance contents, SLSA mandates the following requirements:

Table 4: SLSA4 Build provenance content requirements and SUSE's OBS
Requirement Required at SLSA4 Achieved
Identifies artifact
Identifies builder
Identifies build instructions
Identifies source code
Identifies entry point
Includes all build parameters
Includes all transitive dependencies
Includes reproducible info
Includes metadata

Learn how SUSE's OBS meets the SLSA4 provenance content requirements:

Identifies artifact
  • SLSA L4 requirement.  Identify the output artifact by at least one cryptographic hash included in the provenance.

  • SUSE's processes.  OBS stores SHA2 hashes of all build artifacts in the provenance files.

Identifies builder
  • SLSA L4 requirement.  Provide an identifier for the entity that performed the build with the provenance.

  • SUSE's processes.  The ID of the builder is added by OBS into the provenance files.

Identifies build instructions
  • SLSA L4 requirement.  Provide the top-level instructions that were used to execute the build.

  • SUSE's processes.  The build instructions are the RPM spec file, which is specified in the provenance files.

Identifies source code
  • SLSA L4 requirement.  Include the repository origin/origins for the source code used in the build in the provenance.

  • SUSE's processes.  Met by OBS.

Identifies entry point
  • SLSA L4 requirement.  Identify the entry point of the build definition used to drive the build (for example the source repo the configuration was taken from).

  • SUSE's processes.  The provenance files specify the RPM spec file or container description file as entry point.

Includes all build parameters
  • SLSA L4 requirement.  Include all build parameters that are under a user's control in the provenance.

  • SUSE's processes.  Met by OBS.

Includes all transitive dependencies
  • SLSA L4 requirement.  Include list of all transitive dependencies in the provenance.

  • SUSE's processes.  Met by OBS.

Includes reproducible info
  • SLSA L4 requirement.  Include information on whether the build was intended to be reproducible. If so, also include all information needed to reproduce the build.

  • SUSE's processes.  Met by OBS, but builds are currently marked as non-reproducible.

Includes metadata
  • SLSA L4 requirement.  Include metadata in the provenance to help with debugging and investigations.

  • SUSE's processes.  OBS includes additional metadata into the provenance.

3.4 Common

Every system involved in the supply chain must adhere to a set of strict, common security standards.

Table 5: SLSA4 common requirements and SUSE's OBS
Requirement Required at SLSA4 Achieved
Security
Access
Superusers

Learn how SUSE's software supply chain is kept secure by securing all systems involved:

Security
  • SLSA L4 requirement.  The source control and build systems must meet certain security standards to ensure they cannot be easily compromised.

  • SUSE's processes.  Red team scans for vulnerabilities, build team patches build environment. Machine identity is enforced, user isolation by policy.

Access
  • SLSA L4 requirement.  Make sure that physical and/or remote access is rare and tightly regulated. This includes logging and multi-party approval.

  • SUSE's processes.  Multi-party approval is done when the user is logged in via SSH auth key which is salted.

Superusers
  • SLSA L4 requirement.  Restrict the number of admins allowed to override the above-listed criteria to a bare minimum. Whenever such interaction is required, a second admin must give their approval.

  • SUSE's processes.  The number of superusers in OBS is very small.

4 Outlook

SUSE is up to a great start with its effort to attain SLSA L4 compliance, as SLSA requirements partly overlap with those of Common Criteria EAL4+. This means that several SLSA criteria were met by SUSE's supply chain processes right from the start. The core part of this is our certified and proven build and integration process which uses the Open Build Service technology.

Over the past few months, SUSE has been working on improving and tightening processes and technologies to be able to claim full SLSA L4 compliance.

New to SUSE is providing the information of the build environment (provenance) to the outside world. So far, this kind of information has been kept internal, but now it will be delivered in the in-toto format, allowing external parties to verify the full build environment used for building all SUSE deliverables.

5 Legal notice

Copyright ©2006-2025 SUSE LLC and contributors. All rights reserved.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled GNU Free Documentation License.

SUSE, the SUSE logo and YaST are registered trademarks of SUSE LLC in the United States and other countries. For SUSE trademarks, see http://www.suse.com/company/legal/. Linux is a registered trademark of Linus Torvalds. All other names or trademarks mentioned in this document may be trademarks or registered trademarks of their respective owners.

Documents published as part of the SUSE Best Practices series have been contributed voluntarily by SUSE employees and third parties. They are meant to serve as examples of how particular actions can be performed. They have been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. SUSE cannot verify that actions described in these documents do what is claimed or whether actions described have unintended consequences. SUSE LLC, its affiliates, the authors, and the translators may not be held liable for possible errors or the consequences thereof.

Below we draw your attention to the license under which the articles are published.

Documentation survey