search

slsa-framework / slsa

Supply-chain Levels for Software Artifacts
https://slsa.dev
Other
1.53k stars 222 forks source link

Clarify source-track objective #1072

Closed TomHennen closed 2 months ago

TomHennen commented 3 months ago 
          (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 https://github.com/slsa-framework/slsa/pull/1037#discussion_r1598593653_

TomHennen commented 3 months ago

Please see additional discussion in the referenced comment as well as in this doc