-
Notifications
You must be signed in to change notification settings - Fork 214
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
Clarify source-track objective #1072
Labels
Comments
Please see additional discussion in the referenced comment as well as in this doc |
zachariahcox
added a commit
to zachariahcox/slsa
that referenced
this issue
Jun 28, 2024
fixes slsa-framework#1072 Signed-off-by: Zachariah Cox <[email protected]>
zachariahcox
added a commit
to zachariahcox/slsa
that referenced
this issue
Jul 10, 2024
fixes slsa-framework#1072 Signed-off-by: Zachariah Cox <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It seems to me that the source track (similar to the build track) should start with generating provenance at the lower levels, then move to implementation of specific policies at higher levels.
The revision of a consumed repository is a kind of artifact like any other software dependency and as such should come with all its paperwork. The "build process" of a repository revision is the pull request, and the result of a completed pull request should be a new revision accompanied by provenance claims.
This example appears to be covering the requirements and benefits of a specific policy, similar to the "Build Level 1" dedicated infrastructure requirement.
At a minimum, consumers of a repository revision will want to know the following provenance claims:
Based on this, it seems to me that a focused adaptation of the excellent "build track" summary would work well here. EG:
The SLSA SOURCE track describes increasing levels of trustworthiness and completeness in a repository revision's provenance. Provenance describes what Source Control Provider produced the revision, what process was used, and who the contributors were. The lowest level only requires the provenance to exist, while higher levels provide increasing protection against tampering of the version control system, the provenance, or the revision.
The primary purpose of the source track is to enable verification that the revision followed the expected process. Consumers have some way of knowing what the expected provenance should look like for a given package and then compare each source revision's actual provenance to those expectations. Doing so prevents several classes of supply chain threats.
Originally posted by @zachariahcox in #1037 (comment)
The text was updated successfully, but these errors were encountered: