SLSA 1 & 2 should not require config-as-code

[MarkLodato]

As currently worded, SLSA 1 unintentionally requires that the build steps were defined in some source material, i.e. "config as code". This is a problem because it excludes many build systems where such a mapping is not present or infeasible. Examples: Tekton (more info), LUCI, and Google Cloud Build (unless cloudbuild.yaml-based build triggers are used).

SLSA 1 and 2 were intended to be easily applicable to any build system without significant modification to how that system works. We should therefore alter the requirements to make it more clear that this mapping SHOULD be specified if present, rather than blocking something from reaching SLSA 1 or 2 if the mapping is not present or available.

In particular, the problematic requirements are Identifies Source and Identifies Entry Point.

#100 attempted to fix this by removing the requirements altogether from SLSA 1 & 2. This was met with resistance since it weakened the spec too much.

My suggestion is to rework the requirements:

• At SLSA 1+, require that the provenance identify the independent inputs to the build. If it is config-as-code, this SHOULD be the source repo and entry point if available. Otherwise, it it is acceptable to list the build steps, even if they were ultimately derived from some other source.
• At SLSA 3+, require config-as-code, where the independent inputs are boiled down to a source location and entry point.

We may also need to move the Version Controlled requirement to SLSA 3.

[TomHennen]

FWIW this sounds fine to me, I think we should do it.

[sherzberg-1]

+1. But...

From my reading of #100, it seems like the idea of removing the requirement completely is still somewhat under discussion. This also ties in to #111, which may be important to conclude before lowering the requirements of L1 and L2. But I can see an argument for not making it a requirement at all for (at least) L1 - it does absolutely still provide a benefit (an artifact is guaranteed to have been built by the declared builder), and it does make adoption easier.

So +1, but I think there may be discussion to be had to totally remove the requirement, based on the conclusion of the personas discussion.

[tograla]

Good morning! My two cents after going through this thread and SLSA itself (only spent ~20-or-so minutes).
Requiring config-as-code such that provenance can be trusted seems to stand against how L1 is portrayed in the overview section levels: "Provenance at SLSA 1 does not protect against tampering, but it offers a basic level of code source identification".
In addition, Level1 does not require use of Version Control System which means the bar is quite low (in fact I'd opt for making Version Control required for Level1 but this is another issue).