search

slsa-framework / slsa

Supply-chain Levels for Software Artifacts
https://slsa.dev
Other
1.54k stars 223 forks source link

Clarify that SLSA 3 only guarantees identification of the top-level build config #465

Closed MarkLodato closed 1 year ago

MarkLodato commented 2 years ago

From #464: SLSA 3 only guarantees identification of the top-level build configuration used to initiate the build. It makes no guarantee about what actually happened during the build, particularly the "source" that was built. For example, if GitHub Actions attests to building octocat/Spoon-Knife, all it's saying is that the workflow was defined in that file. There is no guarantee that this workflow actually checked out and built the same repo.

The main reason for this definition is because there is no widely accepted technical definition of "source" (#129) and therefore no corresponding technical control, whereas we can cleanly define top-level build configuration and build a control around it.

This distinction seems to cause a fair amount of confusion, so we should clarify in the v1.0 specification.

shaunmlowry commented 2 years ago

This one's tough. If level 3 is the highest we're proposing for v1.0 I think we need to be a bit tougher here and clearly identify the action that was performed on which inputs in the attestation. I'm not sure I'd really see much value in an attestation that just said "the food we're serving is based on the process of cooking at 400F" without any mention of what was cooked.

+1 on resolving for 1.0 though

TomHennen commented 2 years ago

I agree that getting clarity here would be helpful, I'd probably disagree with that particular metaphor. The provenance including the top level build config would be more like "this dish was made following the recipe 'poached salmon', page 67, of Mastering the Art of French Cooking" without mentioning the specifics like which tools were used, where the ingredients were sourced from, etc...

MarkLodato commented 2 years ago

I agree with @TomHennen. The top-level build configuration does indicate at least the source location, so if you read it, you would at least know what was being checked out. The delta between that and putting it in the provenance is that the latter would resolve it to a specific version/hash.

MarkLodato commented 2 years ago

Removing the maybe-1.0 label as a decision to include it in 1.0.

MarkLodato commented 1 year ago

The current draft v1.0 wording (https://slsa.dev/spec/v1.0/requirements) removes the term "source", but I think the larger issue remains: it is unclear what security SLSA Build L3 buys you. Somewhere we need to explain in plain english (preferably with a diagram) that SLSA Build L3 identifies the inputs to the build, but there needs to be some as-yet-undefined "transitive" analysis to verify the whole supply chain.

MarkLodato commented 1 year ago

I am going to close this issue because I think the current wording is good enough. Please feel free to open more specific feedback on v1.0.