From 27c7142a913d7155e6b117b5e3c12d9fd6ec4a44 Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Fri, 13 Dec 2024 15:42:23 +0000 Subject: [PATCH] Separate out requirements for the org This should, hopefully, make who is responsible for what more clear. Also adding a requirement for summary attestation distribution (mirroring what was done with the build track). I'd like to merge the change management tool requirements into the 'System' Requirements table too, but it's a bigger change so I'll leave that for later. Signed-off-by: Tom Hennen --- docs/spec/draft/source-requirements.md | 35 +++++++++++++++++++++++--- 1 file changed, 32 insertions(+), 3 deletions(-) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index 16f5ced6e..f1d0bf6d8 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -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 +
RequirementDescriptionL1L2L3 @@ -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. ✓✓✓ +
Distribute summary attsetations + +The organization MUST document how [summary attestations](#summary-attestation) are distributed +for relevant source repositories. +✓✓✓ +
Distribute provenance attsetations + +The organization MUST document how [provenance attestations](#provenance-attestations) are distributed +for relevant source repositories. +✓ + +
+ +### System Requirements + + +
RequirementDescriptionL1L2L3
Revisions are immutable and uniquely identifiable This requirement ensures that a consumer can determine that the source revision they have is the same as a canonical revision. @@ -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). +✓✓✓ +
Source Summary Attestations + +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. + ✓✓✓
Branches @@ -206,7 +235,7 @@ See [source roles](#source-roles). ✓
Source Provenance -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. @@ -235,7 +264,7 @@ For example, this could be accomplished by: ✓
-## 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).