Indicating that the build system has a completed set of resolved dependencies

[arewm]

In SLSA v0.1, there was a property called hermetic. If a build is hermetic then the artifact is built in an environment without any unrestricted access outside of the build platform (I commented on this elsewhere previously). This means that the build system should have complete knowledge of all resolved dependencies as all of these need to be made available at build time.

We have a build system (Konflux-ci) built on Tekton + Tekton Chains which conforms to the SLSA build v1.0 L3 spec. This system enables users to optionally configure their pipeline to have network access removed during the build task. They can additionally configure an optional task to prefetch dependencies for many common package managers (gomod, pip, npm, yarn, bundler) which are made available at build time. These fetched dependencies are then used to inform a build-time SBOM.

While I wouldn't imagine it to be possible for Chains to generate a different provenance for these modes of operation, it should be possible for the build system to use a policy engine (i.e. conforma née Enterprise Contract) to validate that the complete resolved dependency requirements are met before further attestations are made. In this scenario, how should we standardize the process of specifying these higher guarantees? If the complete resolved dependencies were part of the build track, then we would easily be able to make a VSA indicating this higher level.

One caveat to this system is that the resolved dependencies are not necessarily complete in the provenance itself, but the dependencies are complete as represented in the produced build-time SBOM. Since Chains cannot generate provenance with multiple builder.ids and since the complete resolved dependencies would not be in the provenance, I wouldn't expect to leverage any changes to the provenance specification. Instead, we would likely have to fall back to a VSA attestation of some SLSA property.

This issue relates to the following:

• Hermetic requirement break-down to lower-levels #230 How to define hermetic as it relates to SLSA. There was some agreement in this issue that hermetic makes sense as a build L4.
• feedback: version SLSA 1.0 dropping / reducing scope from 0.1 is weird #806 It would restore more scope to the spec from 0.1.
• Workstream: SLSA Build L4 #977 SLSA build L4. We previously had some discussion around whether L4 should be reproducibility-related or hermetic-related. Semantic equivalency, reproducible builds, and a new "verifiable build" track #873 is related to this issue as it is a discussion around a separate track dedicated to reproducibility. Comprehensively describe how verification works #1011 is also related to this topic as we have had previous discussions around reproducibility just being a property of verification since it is not a property that can be determined by a single build platform.
• Clarification for completeness of builder ID #1261 Tekton Chains cannot use different builder.ids to differentiate between the potential SLSA levels.