Clarify difference between "Isolated", "Service generated", and "Non-falsifiable"

[MarkLodato]

Currently we have three overlapping requirements:

Service generated (L2): [...] Regular users of the service MUST NOT be able to inject or alter the [provenance] contents, except as noted below.

Non-falsifiable (L3): Provenance cannot be falsified by the build service’s users. NOTE: This requirement is a stricter version of Service Generated. [...specific requirements on the signing key...]

Isolated (L3): [...] It MUST NOT be possible for a build to access any secrets of the build service, such as the provenance signing key.

It's not clear how these three requirements differ from one another, or how L2 differs from L3.

The original intention was as follows:

• L1 can be tacked on to any existing process with no changes to the build service. Provenance can be trivially forged.
• L2 requires relatively inexpensive changes to the build service. Provenance should not be trivially exploitable.
  • Open question: Should it still be strong against key theft?
• L3 may require significant changes to the build service. Provenance must not be exploitable even for a determined adversary.

[joshuagl]

The spec separates "build system" and "provenance generation" requirements. Two of these overlapping requirements are provenance generation requirements and one a build system requirement.

Does that distinction makes the Isolated requirement clearer? It's not just about provenance generation but isolating builds from the build service and other builds.

I think there is another overlapping (provenance) requirement:

Authenticated (L2): The provenance’s authenticity and integrity can be verified by the consumer. This SHOULD be through a digital signature from a private key accessible only to the service generating the provenance.

which seems to me to overlap with non-falsifiable in that authenticated metadata makes falsifying metadata hard.

[MarkLodato]

Let's take a concrete use cases: running cosign within the build, storing the key in a secret manager (example, config). The maintainers of the project could extract the key from the secret manager and use it to falsely sign provenance.

My feeling is that this is SLSA 2 but not SLSA 3. It is clearly generated by a service and protects against tampering after the build (SLSA 2), but it does not protect against the maintainers themselves tampering with the build (SLSA 3).

/cc @samwhite-gl

[samwhite-gl]

Thanks @MarkLodato. I agree with this and feel that it would be beneficial to move this requirement to SLSA level 3. We could perhaps leave some lesser version of this requirement in SLSA level 2. My initial thought is that a new SLSA 2 appropriate requirement might be something like "Scripted Provenance Generation" which would be similar to the "Scripted Build" requirement but would apply to producing the provenance in a scripted/automated manner. This would bridge the gap between SLSA level 1 "Available" provenance and the proposed SLSA level 3 "Service Generated" provenance.

I am not great at wording and naming things, so refinement of this new SLSA level 2 requirement is very welcome.

[MarkLodato]

I suspect that the latest v1.0 draft addresses this well enough. Please open a new issue if it's not sufficiently clear.