Clarify where to use SLSA Provenance vs. VSA

[joshuagl]

In the SLSA specification meeting on 2023-10-02 @MarkLodato suggested to clarify in the specification that:

• SLSA Provenance format makes sense when the consumer can see the source (i.e. is within the same company as the attestor, or is consuming open source).
• When closed source crosses organizational boundaries, SLSA Provenance isn’t especially meaningful. A Verification Summary Attestation (VSA) to claim a SLSA check was performed makes most sense to convey SLSA implementation in this case.
  • It was also noted that the VSA could include a hash of the provenance, which could later be used to prove to an auditor that a provenance attestation matches the claims in a VSA.

[joshuagl]

This feels like a good thing to add to the specification soon, i.e. v1.1

[joshuagl]

  * It was also noted that the VSA _could_ include a hash of the provenance, which could later be used to prove to an auditor that a provenance attestation matches the claims in a VSA.

The inputAttestations field can be used for this purpose, we just need to recommend that.

[arewm]

When closed source crosses organizational boundaries, SLSA Provenance isn’t especially meaningful. A Verification Summary Attestation (VSA) to claim a SLSA check was performed makes most sense to convey SLSA implementation in this case.

It is not just when crossing organizational boundaries. In the specification, the SLSA Provenance format is only a recommendation. It might be too generic to just indicate that VSAs can be used when crossing boundaries, but maybe there can be an additional recommendation if the provenance does not conform to the SLSA Provenance format.

[TomHennen]

Note that the VSA is also especially useful when you want to do recursive/transitive evaluation of a policy against an artifact (and this is in fact why it was originally developed).

Would it be worth noting that as well?

CC @AdamZWu

[kpk47]

* SLSA Provenance format makes sense when the consumer can see the source (i.e. is within the same company as the attestor, or is consuming open source).

This concept generalizes to future SLSA tracks as well, so perhaps the phrasing should be about whether the consumer has sufficient context to evaluate an attestation? For example, even if you can see a repo's source code, you may not be able to see the configuration that determines its Source level. In that case, a signed VSA from the source control system or some other trusted party should be sufficient for verifying Source level.

[joshuagl]

This concept generalizes to future SLSA tracks as well, so perhaps the phrasing should be about whether the consumer has sufficient context to evaluate an attestation?

Absolutely agree, great suggestion.