Clarify that SLSA is intended to be automatically verifiable
As mentioned in #127, we need to clarify that all of the SLSA requirements are intended to be automatically verifiable to some degree. Right now that is completely unstated, which results in confusion and disagreement.
Futhermore, we should explain how we picture verifying these requirements. Examples:
- Version Control: The source listed in the build provenance is either a known version control system (e.g.
git+httpsURI scheme), has an attestation showing it came directly from version control (by matching ondigest), or has some TBD chained verification. - Retention: The source has an attestation from the source control platform claiming that it meets the retention requirement, and the verifier has some global configuration saying which platforms the verifier trust to make that claim. For example, a verifier might trust GitHub's claims about retention.
Regarding the source control system issuing an attestation to these requirements please see https://github.com/in-toto/attestation/issues/47
Note we added mention of the intent for all requirements to be automatically verifiable in https://github.com/slsa-framework/slsa/pull/133#discussion_r690470200
I talked about this a bit with @joshuagl
The idea is that artifacts can be automatically verified to see if they meet a given SLSA level. Systems, however, may need some human analysis to see if they meet their SLSA requirements (e.g. Source & Build requirements).
For example, a security engineer may analyze the architecture and implementation of a build system to ensure that it meets (or can meet) the build requirements. Once the analysis is complete the keys used by the build system can then be 'trusted' up to a given SLSA level.
During verification of artifacts, the verifier can then automatically determine that the build system used meets the build requirements by checking if the keys used to sign the provenance are 'trusted' at the target SLSA level.
Issue https://github.com/slsa-framework/slsa/issues/46 "Policy & Verification" is related to this. As is #478 on achieving automatic verification.
I'm repurposing this issue to cover the general issue of how systems and artifacts are verified to meet the SLSA requirements, de-duplicating other issues here. See the updated top comment for the latest.
Now that we've closed the 'verifying systems' bug, we can close this one as well.