How to convey build service guarantees via attestations

[MarkLodato]

SLSA requires the build service to guarantee various properties, such as isolation between builds, completeness of various provenance fields, or reproducibility. To determine the SLSA level of an artifact, consumers therefore need two things:

• Configuration of what builder is trusted to make what guarantees (or what level).
• Indication by the builder of what guarantees (or level) it claims for a particular build, in case some properties vary from invocation to invocation.

The consumer would then logically "and" (or "min") these together. For example provenance claims that a build is L3 but a consumer only considers the builder L2, then the result is L2.

What builder is trusted to make what guarantees

Currently this concept is not discussed at all on the SLSA site.

An initial first pass would be to say that each consumer has some static configuration that is communicated out of band. For example, a consumer would have some static configuration of what level they trust each builder, with the default being SLSA 1. How they determine that is unspecified.

Down the road, it might be desirable to define a "builder level" attestation, meaning that some party (the attester) attests that the subject (the builder) meets certain properties and/or a certain level. This is essentially turning the configuration from the previous paragraph into an attestation. The consumer can make their own attestation for this (to keep the same behavior) or can delegate trust to some other party. This would depend on future attestation support for non-digest subjects (in-toto/attestation#5).

Guarantees claimed by the builder

Currently https://slsa.dev/provenance/v0.1 only covers some properties, namely metadata.completeness.* and metadata.reproducibility. This seems inconsistent. We should have a more reasoned approach to communicating these properties.

I'm not sure of the best solution here. Some ideas:

• In the provenance, have a dedicated field for each SLSA requirement. To meet a SLSA level, all properties must be specified positively.
  • Pro: explicit
  • Con: verbose
• Same as above, but allow per-builder defaults. That is, there is some configuration that maps builder.id to a list of default values.
  • Pro: more compact
  • Con: more complex
• In the provenance, only have a "SLSA level" field, which in turn would map to the list of guarantees.
  • Pro: more compact
  • Pro: possibly easier to use
  • Con: no ability to mix-and-match properties across SLSA levels
  • Con: more room for the builder to mess room
  • Con: requires mapping from SLSA level to guarantees

[MarkLodato]

Suggestion from @dlorenc in #210 (comment): list the claims as a list of namespaced strings rather than dedicated fields. That avoids the bool vs enum issue, is more extensible, and more expressive. Here's a tweak from Dan's suggestion:

builderClaims:
- https://slsa.dev/claims/FullyReproducible
- https://slsa.dev/claims/DependenciesComplete