Unique builder.id for SLSA Build > L3

[arewm]

In identifying requirements for isolation in Build L3, we agreed that L3 would not require specific producer modification to the builds while starting with L4 that the producer and the platform will need to take on additional work before being able to achieve these higher levels.

In the Provenance specification, it is noted

If a build platform has multiple modes of operations that have differing security attributes or SLSA Build levels, each mode MUST have a different builder.id and SHOULD have a different signer identity. This is to minimize the risk that a less secure mode compromises a more secure one. [link]

This requirement makes sense when considering Build levels 1, 2, and 3 since there are no required actions for the producer's build other than using a platform capable of achieving the desired level. When considering a future Build L4, however, this requirement starts to add confusion as the build platform might not have a priori knowledge of the achieved SLSA Build level.

If a build platform is capable of achieving a Build L4 due to the additional hardening that it achieves, it might be a usability feature for such a platform to also support L3 based on producer input and configuration. These build systems would then be able to assess the produced artifact (and supporting attestations) to definitively classify a build as L3 or L4 based on user configuration. In this situation, it would make sense that a builder.id attached with the provenance is associated with the maximum possible SLSA build level.

In these situations, it may require that a build platform produces its own VSA attestation to clearly identify the achieved build level for each artifact due to the implementation of the platform to improve usability.

[arewm]

Bringing in a comment from slsa-framework/slsa-proposals#9 (comment)

@kpk47 mentioned

if a platform is capable of producing different level provenance based on user inputs then we have to trust it to use the right builder ID. The process they use to choose the builder ID could also produce a VSA, but I'm not convinced it buys us anything. I'm not decided yet.

Since a build platform can fall back to the most interoperable format of SLSA verification of artifacts -- i.e. VSA -- for confirming and indicating what the actual SLSA level is, it would be at a disadvantage from the platform's usability perspective to disallow producer flexibility when configuring builds on the platform. Instead, it would be advantageous to

1. Create a service capable of achieving the desired SLSA level by a producer (i.e. the current level and all higher)
2. Inform producers which SLSA level their artifacts are conformant with
3. Clearly describe the changes needed for producers to change the achieve SLSA build level
4. Confirm the achieved build level once the producer has achieved a higher bar of build hardening

In order to make this process usable, producers shouldn't be dissuaded from the journey so artifacts should continue to be built as the build hardening is occurring. The moment that builds achieve a higher build level, they should be classified as such by the build platform.

In order for a build platform to be able to choose a correct ID, the platform has to be able to detect the "chosen path" before the builder.id is configured (which might happen very early in the process, i.e. before any of the user input has been fully processed). If a build platform cannot identify the chosen path by the time that the builder.id set, however, one potential alternative would be for the platform to create a VSA attestation for the produced artifact (via a different process after the build is completed but before the user is notified of the result). While it may not be possible to make a pre-determination of the intended SLSA level, it MUST be possible for a build platform to make a post-determination.

[arewm]

I had a conversation with @TomHennen about this at SOSS-EU. While this isn't a summary of the conversation, it is a re-assessment of my original issue in light of the conversation.

The provenance specification indicates

URI indicating the transitive closure of the trusted build platform. This is intended to be the sole determiner of the SLSA Build level.

While it may be a great feature for a build platform to support multiple modes of operations, there should be some process which simplifies the consumption process, whether that is re-attesting an updated provenance with a unique builder.id or generating a VSA that indicates the SLSA level.

If a build platform does not adhere to this requirement for builder.id, it can still claim specific SLSA levels but it isn't strictly using the SLSA provenance format (which is only RECOMMENDED in the build track).

Strictly speaking, the mode of operation for the type of build platform that I described above may be described as a single mode (even if that mode is flexible). That mode might just enable users to self-select more restrictive modes which the build platform would then need to verify before claiming higher SLSA levels. Therefore, the builder.id would be consistent for all artifacts (and would be indicative of the LOWEST SLSA level achievable in that mode of operation).