search

slsa-framework / slsa

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

Update "build as code" requirement to allow for build configuration stored in alternative locations #368

Closed bobcatfish closed 2 years ago

bobcatfish commented 2 years ago

The "build as code" requirement currently states that build definitions and configuration must be stored in version control, however there may be other ways to meet this requirement.

The spirit of the requirement seems to be that ultimately the definition should still be traceable back to version control but perhaps it can also be met by build definitions which are published from there to an intermediate location - for example Tekton has the concept of a Tekton Bundle which is Tekton Task or Pipeline definitions that have been published to an OCI registry.

It would be great to update the "build as code" requirement to make it clear that while ultimately the origin of the build definition should be traceable back to version control (e.g. via provenance stored in the same OCI registry in the case of Tekton Bundles), not that the definition must have been fetched directly from version control.

(More context available in SLSA + Tekton: Case Study - the doc is visible to anyone in mailing list slsa-discussion@googlegroups.com )

mlieberman85 commented 2 years ago

I think we should clarify it a bit. The intent is to just ensure that the code describing a build has adequate provenance that can be traced back through some process involving approvals, trusted identities etc. However as written I agree that it really seems to indicate only build coming straight from source would count.

I think Tekton Bundles and similar do count as long as you have some way to trace those bundles back to the source. We plan to do something similar for "ssf" which uses Tekton and the idea would be to have SLSA provenance attestations for the Tekton bundles themselves and so the bundle would have the source as "materials"

joshuagl commented 2 years ago

I attempted to refine the description of "Build as code" but only managed this:

Build as code

The build definition and configuration which are executed by the build service is verifiably derived from text file definitions stored in a version control system.

Examples: .github/workflows/build.yaml stored in git, Tekton bundles generated from text files by a SLSA compliant build process and stored in an OCI registry with SLSA provenance metadata available.

The Tekton example feels verbose and a little circular.

joshuagl commented 2 years ago

Derive may not be a good choice, as it can be interpreted to mean extracted from (and perhaps not in its entirety).

Perhaps "must verifiably originate from text file definitions in a version control system"?

MarkLodato commented 2 years ago

I think your refinement is an improvement. I have no problem with "derived". It could probably use another sentence explaining what "verifiably derived" means, i.e. that it's either fetched directly through a trusted channel or it has some trustworthy provenance chain linking back to version control.

joshuagl commented 2 years ago

Thanks Mark, I've submitted #386 to capture the refinement proposed here.