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.

Sign up for GitHub

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

content: draft: Clean up source 'levels' table #1259

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

content: draft: Clean up source 'levels' table #1259

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
27c7142
Separate out requirements for the org
TomHennen Dec 13, 2024
1a11c6d
slight wording tweaks
TomHennen Dec 13, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 32 additions & 3 deletions docs/spec/draft/source-requirements.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -108,10 +108,12 @@ Benefits:
Provides authenticatable and auditable information to policy enforcement tools and reduces the risk of tampering
within the SCS's storage systems.

## System Requirements
## Requirements

Many examples in this document use the [git version control system](https://git-scm.com/), but use of git is not a requirement to meet any level on the SLSA source track.

### Organization Requirements

<table>
<tr><th>Requirement<th>Description<th>L1<th>L2<th>L3

Expand All @@ -131,6 +133,23 @@ Branch protection is not required, nor are there any other constraints on the co
The source MUST have a location where the "official" revisions are stored and managed.

<td>✓<td>✓<td>✓
<tr id="distribute-summary-attestations"><td>Distribute summary attsetations<td>

The organization MUST document how [summary attestations](#summary-attestation) are distributed
for relevant source repositories.
<td>✓<td>✓<td>✓
<tr id="distribute-provenance-attestations"><td>Distribute provenance attsetations<td>

The organization MUST document how the detailed [provenance attestations](#provenance-attestations)
are distributed for relevant source repositories.
<td><td><td>✓

</table>

### Source Control System Requirements

<table>
<tr><th>Requirement<th>Description<th>L1<th>L2<th>L3
<tr id="immutable-revisions"><td>Revisions are immutable and uniquely identifiable<td>

This requirement ensures that a consumer can determine that the source revision they have is the same as a canonical revision.
Expand All @@ -151,6 +170,16 @@ When the revision ID is a number or otherwise not a digest, then the SCS MUST do
The same revision ID MAY be present in multiple repositories.
See also [Use cases for non-cryptographic, immutable, digests](https://github.com/in-toto/attestation/blob/main/spec/v1/digest_set.md#use-cases-for-non-cryptographic-immutable-digests).

<td>✓<td>✓<td>✓
<tr id="source-summary"><td>Source Summary Attestations<td>

The SCS MUST generate [summary attestations](#summary-attestation) to enable users to determine the source level of a given revision.

If a consumer is authorized to access source on a particular branch, they MUST be able to fetch the summary attestations for revisions in the history of that branch.

It is possible that an SCS can make no claims about a particular revision.
For example, this would happen if the revision was created on another SCS, or if the revision was not the result of an accepted change management process.

<td>✓<td>✓<td>✓
<tr id="branches"><td>Branches<td>

Expand Down Expand Up @@ -206,7 +235,7 @@ See [source roles](#source-roles).
<td><td><td>✓
<tr id="source-provenance"><td>Source Provenance<td>

Source Provenance are attestations that contain information about how a specific revision was created and how it came to exist in its present context
[Source Provenance](#provenance-attestations) are attestations that contain information about how a specific revision was created and how it came to exist in its present context
(e.g. the branches or tags that point, or pointed, at that revision).
They are associated with the revision identifier delivered to consumers and are a statement of fact from the perspective of the SCS.

Expand Down Expand Up @@ -235,7 +264,7 @@ For example, this could be accomplished by:
<td><td><td>✓
</table>

## Change management tool requirements
### Change management tool requirements

The change management tool MUST be able to authoritatively state that each new revision reachable from the protected branch represents only the changes managed via the [process](#change-management-process).

Expand Down
Loading