Build Environment track threats

[paveliak]

Build track defines requirements for the provenance that is generated for the build artifacts. Trustworthiness of the build provenance largely depends on the trustworthiness of the environment the build runs in. Build track assumes full trust into the Build Platform providing no solutions to verify build environment integrity. Build Environment track intends to close this gap.

Build environment is bootstrapped from a build image, which is expected to be an artifact of a SLSA build pipeline. Build platform verifies image provenance upon starting up the environment and provides evidence to the tenant.

Bootrapping the build environment is a complex process, especially at higher SLSA levels. Build L3 usually requires significant changes to existing build platforms to maintain ephemeral build environments. It is not uncommon for the build platforms to rely on public cloud providers for managing compute resources that power build environments. This in turn might significantly increase attack surface because added build platform dependencies effectively become part of the TCB.

Build Environment track addresses TCB size concerns at L2 and L3 levels. L1 level assumes full trust into the Build Platform including underlying Compute Platform (eg. public cloud provider). L2 level adds capabilities for verifying Compute Platform. L3 level removes Compute Platform from TCB rooting the trust into the hardware.

Threat model

This diagram outlines the lifetime of a build image between it being generated and used for creating a build environment. Image could be compromised at different times (components). Higher SLSA levels secure the build environment from a larger amount of threats.

flowchart LR
      BuildImage>Build Image] ---> |L1|BuildPlatform[[Build Platform]]
      BuildPlatform[[Build Platform]] ---> |L2|ComputeProvider[[Compute Provider]]
      ComputeProvider[[Compute Provider]] ---> |L3|BuildEnvironment[(Build Environment)]

Loading

L1 level protects from threats that happened to the build image in between generating it and passing to the Build Platform. This covers cases of unauthorized modifications happening to the image as it is distributed (potentially via untrusted channels).

L2 level protects from threats occurring at the Build Platform side as it interacts with the Compute Provider for actually creating a build environment. Control plane is the only Build Platform component that is considered trusted at L2 as it performs remote attestation of the build environment.

L3 level protects from threats coming from the Compute Provider. It requires build running in a trusted execution environment using technologies like AMD SEV and Intel TDX. Compute provider is considered untrusted at L3 with the trust rooted into hardware.

NOTE: Control Plane is considered trusted at L2 and L3 as it performs remote attestation of the build environment. Build platforms may provide capabilities that let tenants perform remote attestation themselves. However, for the Control Plane to be considered untrusted it should have no back-door access to the build environment (e.g. via SSH). Besides, Control Plane provides input data to the build environment (i.e. build request message) and security risks associated with compromising inputs have to be considered as well.

What follows are the example threats.

Invalid build image

Threat: Wrong image is used for the build environment. This could be a dev/test image or an older version of the image having security vulnerabilities.

Mitigation: Control Plane verifies build image provenance upon creating build environment. Needs L1 level

Example: Malicious actor gained access to the build image supply chain and was ultimately able to configure the wrong image in the Build platform.

Root file system integrity

Threat: Malicious software is deployed to the build environment via unauthorized access to the root file system.

Mitigation: Root file system is protected by file system integrity solutions like dm-verity and is measured in the TPM. Or the root file system is encrypted with the encryption key released to the build environment after it has passed remote attestation. Needs L2 level.

Example: Malicious actor gained unauthorized access to the build environment root file system and was able to modify it. For a build image that is served remotely via a network file system (NSF) or a network block device (NBD) this could happen if the remote server is compromised or data was compromised at rest.

Reused build environment

Threat: Build environment unexpectedly reused across two or more builds

Mitigation: Unique build identifier is included into the Build environment provenance (and TPM measurement) allowing Control plane to detect environment reuse. Needs L2 level

Example: Due to a bug in the build platform, the environment was used for running two or more jobs and effectively losing “ephemeral” property. Malicious actors could use this vulnerability to poison the build environments they should not have access to.

Continuous integrity of the build environment

Threat: Build environment integrity was compromised due to unauthorized access on the Compute provider side.

Mitigation: Trusted execution environment provided by hardware-assisted mechanisms like AMD SEV and Intel TDX secures access to the build environment state even in the event of a fully compromised compute provider. Requires L3 level.

Example: Malicious actor (potentially a rogue administrator) was able to retrieve encryption secrets from the build environment memory and modify contents of the root or temporary file system (used to store transient data including build artifacts).

CC @marcelamelara

[marcelamelara]

Thank you for getting this started @paveliak :) I really like where you're going with this, and it's quite similar to what we had in our very first proposal for this track:

Tampering during build environment image generation/distribution

Attacks on the generation process of a build image can result in persistent backdoors baked into the build image and therefore result in wide compromise.

This can be addressed via L1, and is a specific case of SLSA threat D.

Tampering during build execution

An attacker with temporary access to the compute platform during build execution can modify the software or hardware components underlying the build environment to modify build outputs or modify inputs before they are used in the build steps.

I think this one is no longer in scope for the BuildEnv track, since it relates to runtime integrity.

Tampering at build image boot time

With temporary access to the compute platform/host system, an attacker may target the instantiation/boot process of the build environment, which could allow them to embed a malicious kernel or build agent with minimal detection ability by the tenant.

This can be addressed via L2.

Tampering during build dispatch

For performance, build platforms often run a pool of idle build environments waiting to receive a new build job. An attacker with temporary access to the build environment during the period before a build job is started may replace common tools with malicious ones, or start monitoring software that can sniff for secrets used in continuous deployment, or introduce backdoors that can provide more persistent access during the job.

This one can be addressed via L3.

---

Two interesting things stand out to me immediately:

• It's interesting that for L2, you specifically call out the root FS as being the attack, where I am thinking a bit more broadly, including the network, or even the bootloader itself as being potentially compromised to replace the "good" build image with a bad one at boot time. Does this require us to remove (parts of) the hypervisor out of the TCB at L2?
• Detecting build image reuse is not a case we had considered, but I think it would be really awesome if the BuildEnv track could help mitigate this. I even think that this feature wouldn't significantly increase the burden on build platforms at L2 because we're already requiring them to track the TPM measurements anyway, so I think this is mostly a matter of ensuring that the unique "build ID" is generated properly when the build environment starts up.