v1.0: Clarify that systems are manually verified, artifacts are automatically verified

[MarkLodato]

As @TomHennen said in https://github.com/slsa-framework/slsa/issues/130#issuecomment-914317886:

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).

Let's work that into the specification for v1.0.

• [x] Explain that systems are manually verified, artifacts are automatically verified
• [x] Explain that the SLSA rating is in the eye of the beholder. Each consumer may arrive at a different conclusion, though accreditation may come into play. Maybe we can frame this around "roots of trust"?
• [x] #508
• [x] #46

---

Original text

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+https URI scheme), has an attestation showing it came directly from version control (by matching on digest), 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.

[TomHennen]

Regarding the source control system issuing an attestation to these requirements please see https://github.com/in-toto/attestation/issues/47

[joshuagl]

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

[TomHennen]

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.

[joshuagl]

Issue https://github.com/slsa-framework/slsa/issues/46 "Policy & Verification" is related to this. As is #478 on achieving automatic verification.

[MarkLodato]

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.

[kpk47]

Now that we've closed the 'verifying systems' bug, we can close this one as well.