-
Notifications
You must be signed in to change notification settings - Fork 219
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v1.0: Clarify that systems are manually verified, artifacts are automatically verified #130
Comments
Regarding the source control system issuing an attestation to these requirements please see in-toto/attestation#47 |
Note we added mention of the intent for all requirements to be automatically verifiable in #133 (comment) |
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. |
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. |
As @TomHennen said in #130 (comment):
Let's work that into the specification for v1.0.
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:
git+https
URI scheme), has an attestation showing it came directly from version control (by matching ondigest
), or has some TBD chained verification.The text was updated successfully, but these errors were encountered: