Build Environment track

Rationale

Today’s hosted build platforms play a central role in an artifact’s supply chain. Whether it’s a public cloud-hosted service like GitHub Actions or an internal enterprise CI/CD system, the build platform has a privileged level of access to artifacts and sensitive operations during a build (e.g., access to producer secrets, provenance signing).

This central and privileged role makes hosted build platforms an attractive target for supply chain attackers. Similarly, cloud providers are big companies with complex infrastructure that is not immune to compromise.

Even with strong economic and reputational incentives to mitigate these risks, it’s very challenging to implement and operate fully secure build platforms because they are made up of many layers of interconnected components and subsystems. Platforms today provide limited abilities to scope the context of trust, or to continuously validate components over time when using their services.

The SLSA Build Environment track aims to address these issues by making it possible to validate the integrity and trace the provenance of core build platform components.

Track overview

The SLSA Build Environment (BuildEnv) track describes increasing levels of integrity and transparency of a build’s execution context. In this track, provenance describes how a build image was created, how the hosted build platform deployed a build image in its environment, and the compute platform they used.

:warning: The Build Environment track L1+ currently requires a hosted build platform. A future version of this track may generalize requirements to cover bare-metal build environments.

:grey_exclamation: We may consider the addition of an L4 to the Build Environment track, which covers hardware-attested runtime integrity checking during a build.

Relationship with the SLSA Build track

The Build track defines requirements for the provenance that is produced for the build artifacts. Trustworthiness of the build process largely depends on the trustworthiness of the build environment the build runs in.

However, the Build track assumes full trust in the build environment, and provides no requirements to verify its integrity. The BuildEnv track intends to close this gap through an approach that enhances the transparency of the build environment in a way that complements the Build track.

Build environment model

The Build Environment (BuildEnv) track expands upon the build model by explicitly separating the build image and compute platform from the abstract build environment and build platform. Specifically, the BuildEnv track defines the following roles, components, and concepts:

TODO: Disambiguate similar terms (e.g., image, build job, build executor/runner)

Build environment lifecycle

A typical build environment will go through the following lifecycle.

1. Build image creation: A build image producer creates different build images through a dedicated build process. For the SLSA BuildEnv track, the build image producer outputs provenance describing this process.

2. Build image distribution: A build image producer distributes the build image and makes it available for usage on hosted build platforms.

3. Build environment setup: A hosted build platform typically sets up a build environment in two steps.

   i. Boot process: The control plane calls into the host interface to boot a new instance of a build environment from a given build image.

   ii. Build environment admission: The booted build environment is admitted into the pool managed by the control plane. The build agent waits for an incoming build request.

   For the SLSA BuildEnv track, the host interface in the compute platform attests to the integrity of the environment’s initial state during its boot process. The trusted control plane validates this attestation during the build environment admission step.

4. Build dispatch: When the tenant requests a new build, the hosted build platform assigns the build to an already-set up build environment. For the SLSA BuildEnv track, the build platform attests to the binding between a build environment and build ID.

5. Build execution: Finally, the build agent within the environment executes the tenant’s build definition.

Build environment threats

A build environment could be compromised at any stage of its lifecycle. The SLSA BuildEnv levels incrementally address several classes of threats to the build environment.

For example threats, refer to the Build Threats section.

Build image distribution threats

An attacker may make unauthorized modifications to the build image during build distribution, i.e., in between image creation and consumption (e.g., pulling the image from a shared registry) by the build platform. This tampering may occur on the registry or as the build image is transmitted (potentially via untrusted channels).

BuildEnv L1 addresses threats that can happen during build image distribution by requiring that build images be created following the SLSA Build track. BuildEnv L1 also assumes full trust in the build platform including the underlying compute platform (e.g., public cloud provider).

Build environment setup threats

An attacker may tamper with the bootstrapping process of the build environment to instantiate a build environment with compromised boot components (e.g., UEFI firmware). If an attacker manages to compromise build platform admin credentials, these can be used to gain malicious access to the build environment via installed compute platform maintenance software. While such software is typically used for providing remote admin access to the build environment using compute platform APIs, it can also be used to modify components during the build environment’s instantiation, admission or dispatch stages.

These threats cannot be mitigated by only checking a build image’s SLSA Build Provenance because they take advantage of the time window between the check and when the running build environment is booted and used in a build (i.e., a so-called Time-of-check-to-Time-of-use, or TOCTTOU, attack).

BuildEnv L2 addresses these threats by requiring that the build environment’s integrity be verified at every stage of its lifecycle. This, in turn, relies on evidence provided by the compute platform’s host interface showing the build environment’s pre-build state. In essence, BuildEnv L2 provides transparency of the lifecycle’s integrity of a build environment.

The compute platform is fully trusted at BuildEnv L2 as the level relies on the host interface to perform a build environment’s measurements. It remains the responsibility of the build image producer to disable/uninstall any admin interfaces that could be misused by an attacker.

Build environment execution threats

Attackers may seek to compromise a build platform’s runtime infrastructure, and thereby any builds it executes, or circumvent any build environment integrity checks, through vulnerable/malicious software within the compute platform or its host interface. These threats may also arise from compromised compute platform admin credentials that would allow direct access to compute platform software. These threats cannot be mitigated by the approaches used at L1 and L2.

BuildEnv L3 reduces the compute platform attack surface through the use of hardware-based attestation, commonly provided by a trusted execution environment (TEE). The AMD SEV-SNP/Intel TDX threat model describes how this level of trust reduction can be achieved through the use of memory encryption and integrity checking, as well as remote attestation with cryptographic keys that are certified by the compute platform’s hardware manufacturer.

BuildEnv L3 therefore extends a build environment’s lifecycle integrity to to its execution. That is, L3 requires hardware-attested evidence that the build environment was instantiated from the expected build image and is running within a legitimate hardware environment supporting the above integrity properties, bringing transparency to the compute platform.

See the AMD SEV-SNP/Intel TDX threat model for a more detailed list of compute platform level threats.

Trusted components and track scope

The BuildEnv track assumes full trust in the following components. Risks that are out of scope may be considered in a future version of the BuildEnv or other SLSA track.

The build agent and control plane are trusted at all levels because they attest and verify, respectively, the integrity of the build environment.

• Reducing trust in the control plane is out of scope, and would require measures like removing back-door access to the build environment (e.g., via SSH).
• The control plane provides input data to the build environment (i.e., build request message). Mitiating security risks associated with compromised inputs are also out of scope.

The software that ships with the build image or is installed at runtime is trusted at all levels, but may be optionally verified for enhanced integrity checking at higher levels of the BuildEnv track.

• Vulnerabilities in the software that is legitimally included in the build image are out of scope.
• Addressing attempts to circumvent the integrity protections provided by the BuildEnv track by malicious software with privileged access within the build environment is also out of scope.
• Build image producers should manage vulnerabilities in the image components to reduce the risks of such attacks, e.g. by using the SLSA Dependency track and hardening images with mandatory access control (MAC) policies.
• The control plane may perform additional analysis of build image supply chain information like SBOM as part of build environment bootstrapping.
• As the build agent running within the build environment is typically authenticated by the control plane in practice, this track deems checking the agent’s integrity as sufficient during authentication. As with other build environment software, vulnerability detection in the build agent is out of scope.

Physical and side-channel attacks on the build or compute platform, including any trusted execution hardware, are out of scope.

BuildEnv levels

The primary purpose of the Build Environment (BuildEnv) track is to enable auditing that a build was run in the expected execution context. It is not uncommon for the build platforms to rely on public cloud providers to manage the compute resources that power build environments. This in turn significantly expands the attack surface because added compute platform dependencies become part of the trusted computing base (TCB).

The lowest level only requires SLSA Build L2 Provenance to exist for the build image, while higher levels incrementally reduce the TCB size of the build environment, and provide increased integrity checking of the build environment.

Hence, the highest levels of the BuildEnv track introduce further requirements for hardware-based hardening of the compute platform aimed at reducing the TCB of a build environment.

Software producers and third-party auditors can check attestations generated by the build image producer and build platform against the expected properties for a given build environment. This enables any party to detect several classes of supply chain threats originating in the build environment.

As in the Build track, the exact implementation of this track is determined by the build platform implementer, whether they are a commercial CI/CD service or enterprise organization. While this track describes general minimum requirements, this track does not dictate the following implementation-specific details: the type of build environment, accepted attestation formats, the type of technologies used to meet L3 requirements, how attestations are distributed, how build environments are identified, and what happens on failure.