Skip to content
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

Open
TomHennen opened this issue Jun 17, 2024 · 1 comment · May be fixed by #1083
Open

Clarify source-track objective #1072

TomHennen opened this issue Jun 17, 2024 · 1 comment · May be fixed by #1083

Comments

@TomHennen
Copy link
Contributor

          (The "Threat A" url references a deleted ref.)

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.

Concretely: an attacker must compromise the accounts of two organization members to publish code in a Source Level 3-conformant repository, and the evidence of those unauthorized changes cannot be destroyed without further attacks.

At a minimum, consumers of a repository revision will want to know the following provenance claims:

  1. Who contributed these changes (according to the SCP)?
  2. When did they do so (according to the SCP)?
  3. What policy compliance claims are associated with this revision (according to the SCP)?

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)

@TomHennen
Copy link
Contributor Author

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
zachariahcox added a commit to zachariahcox/slsa that referenced this issue Jul 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 🆕 New
1 participant