Workstream: Hardware Attested Build Environments

[chkimes]

This is a tracking issue for incorporating Hardware Attested Platforms, aka Trusted Computing into SLSA. The main idea is to provide greater trust in the build by using trusted computing features like Trusted Execution Environments (TEEs) of modern CPUs to reduce the risk of tampering and to increase transparency.

Workstream shepherd: Marcela Melara (@marcelamelara), Pavel Iakovenko (@paveliak)

Working proposal: #1051
Proposal doc: here

Related: We might want to merge with #977 (Build L4, discussing reproducible builds) and/or #985 (about hardening operations) as discussed in below.

Sub-issues:

• content: draft: Add attested build environment track #1115
• Add detailed requirements description
• Describe implementation options
• Describe the verification model
• Transfer image-attestation demo to slsa-framework org #1110
• What is the best term to describe a build runtime environment's storage? #1107
• Attesting to the builds environments of distributed builds #1122

---

In the 2023-09-13 Supply Chain Integrity meeting, @marcelamelara and I presented on a potential new SLSA track, using cryptographic primitives provided by hardware to validate build environments.

Slides: https://docs.google.com/presentation/d/11cycDxYaoZpuG144pR6atI1_zk2CfZOWlNO_f_HhhyE
Doc: https://docs.google.com/document/d/1l7IKAli-K-uof8VkLuiqV5-hMGS_ecDmBcuc07-ILeQ/edit
Recording: TBD pending upload to YouTube

Some points for discussion, seeding some from the SCI meeting:

1. Is this a new track or an extension of other tracks?
2. I've labeled this as the Build Platform Operations track, however the Future Directions page defines a set of requirements that are likely only verifiable through audit, whereas the attestations defined above are verifiable at runtime. Is this the appropriate track to be defining these in or is there yet another track to distinguish these?

[MarkLodato]

I think this isn't really specific to Build platform. Maybe just "Platform" or "Platform Operations" or "Platform Security" track? For example, once we have a Source track, the same requirements will likely apply there, too.

[chkimes]

@MarkLodato I'm trying to reason through what you mean by that but I'm not sure I follow. The doc describes a handful of cryptographic operations that can be executed in the build environment, not only by the platform to provide their own attestations about the environment but also by a consumer who wants to perform their own validation. I think this property is unique to CI because the consumer can execute whatever they want inside the build environment.

We are also looking at fleshing out some requirements that can't be validated in the same way - the distinction we have been drawing there is that some requirements are "verifiable" whereas others are "auditable" (e.g. requiring a third-party investigation and attestation that certain requirements are being met). Is that where you see the overlap with things like the Source track?

[MarkLodato]

I'm sorry, I saw "Build Platform Operations" but didn't read the actual proposal or your questions. Upon further review, I agree that it's not "Build Platform Operations" but more of a "Hardware Attested Build". I also am not sure it's necessarily a new track. I'll update this issue and create a separate one for the Operations track.

[MarkLodato]

This also seems related to the reproducible builds discussion in #977. In both cases, we want stronger guarantees that the build platform is not compromised. With reproducible builds, we do that by running the build multiple times by independent parties. With trusted computing, we rely on hardware built into modern CPUs. In both cases, we increase the cost of attack.

It also seems to overlap with Operations track in #985. Yet again, it's about preventing an operator from influencing the build.

Maybe it makes sense to merge all three ideas into a new Build level or two (L4 or L5) that describes this higher property - that an operator of a single build platform has no way of influencing the build, even if they collude with colleagues?

@david-a-wheeler @arewm

[marcelamelara]

I'm going to push back a little bit on the notion that requirements on platform operations (implemented by operators) should be merged with the Build track (implemented by developers). I do think that choosing a verifiable build platform (whether that's reproducible and/or HW-attested etc.) should correspond to a higher Build track level, but from a separation of responsibilities standpoint, I think that defining integrity properties and requirements for build platform operators does warrant a separate track.

The other comment I'll make is that from a platform operator view, implementing a verifiable build platform will require us to dive one layer deeper into the different components. Even though we tend to think of build platforms as a single unit, this isn't really true in practice. For instance, one challenge we've come across is defining requirements for cases in which the build platform doesn't necessarily own/provide all of its own infrastructure (e.g., in GH's case, the build VMs run on Azure, introducing additional operators from third parties). So, we've found that we'll have to identify these trust boundaries and components within a build platform so that SLSA may define requirements for these various pieces. We've made a first attempt at this in our current build platform model. We've laid out a number of requirements for build platform operators in our Draft Doc, though they are currently guided by what is feasible through hardware-based mechanisms. I'd be very interested in hearing others' thoughts on whether those requirements are 1) sufficient and 2) generalizable to other verifiable platform approaches.

EDIT: In case this wasn't clear from my comments above, I want to distinguish between HW-attested builds and HW-attested platforms. HW attestations don't attest to application behavior, they attest to platform integrity and need to be enabled by the platform operator, so I think we need to be careful not to conflate the two concepts.

[jkjell]

@MarkLodato's earlier comment got me thinking if this could be generalized to something like a "Hardware Attested Supply Chain Steps". That's definitely a terrible name so, please don't actually use that. 😅

I know that SLSA is primarily concerned with Build today but, I could see additional tracks with recommendations for static analysis, testing, or vulnerability scanning. Even in the case of a source track, many organization are running and host their own source code repositories (Gitlab, Github Enterprise, etc) and will be concerned with tampering of those systems. Or a developer's laptop could be tampered with upon committing code.

From the threats in the document I could see a generalization towards something like:

1. Tampering at platform boot time -> Remains same
2. Tampering during build init -> Tampering during step init
3. Tampering during build execution -> Tampering during step execution
4. Tampering with build environment image generation -> Tampering with step results
5. Tampering with/misuse of control plane/build cache resources -> Tampering with cached resources

The modification or tampering with source code, an SBOM, vulnerability database, vulnerability scan results, static/dynamic analysis findings, or many other supply chain steps could certainly compromise a software supply chain.