content: Add Source Track Level definitions #1066
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ Deploy Preview for slsa ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
4ac688e
to
6713ecd
Compare
Replace multi-factor authentication by strong authentication as other mechanisms can be considered strong authentication. Defer presentation of possible mechanisms in the separate 'source-requirements.md'
lehors
reviewed
Jul 22, 2024
| what the expected provenance should look like for a given source revision and | ||
| then compare each source revision's actual provenance to those expectations. | ||
| Doing so prevents several classes of supply chain threats, mainly threats from | ||
| A to C in the SLSA Supply Chain threats model. |
There was a problem hiding this comment.
Suggested change
| A to C in the SLSA Supply Chain threats model. | |
| A to C in the [SLSA Supply Chain threats model](threats-overview.md). |
Comment on lines
+247
to
+249
| revision followed the expected process. Consumers have some way of knowing | ||
| what the expected provenance should look like for a given source revision and | ||
| then compare each source revision's actual provenance to those expectations. |
There was a problem hiding this comment.
I have a hard time parsing this sentence. I assume this is meant to say that this is also what the source track enables but it doesn't say that and seems to simple state a fact, that's actually not one.
| <dt>Requirements<dd> | ||
|
|
||
| - Version Controlled: Every change to the source MUST be tracked in a | ||
| version control system |
There was a problem hiding this comment.
Suggested change
| version control system | |
| version control system. |
Comment on lines
+300
to
+301
| - Makes easier for consumers the analysis of changes between two given | ||
| revisions |
There was a problem hiding this comment.
Suggested change
| - Makes easier for consumers the analysis of changes between two given | |
| revisions | |
| - Makes the analysis of changes between two given revisions easier for | |
| consumers. |
Comment on lines
+295
to
+296
| - Immutable references: A given revision ID MUST identify unequivocally a | ||
| given revision |
There was a problem hiding this comment.
Shouldn't this tie which revision this is about with something like:
Suggested change
| - Immutable references: A given revision ID MUST identify unequivocally a | |
| given revision | |
| - Immutable references: A given revision ID MUST identify unequivocally that | |
| given revision |
Comment on lines
+320
to
+321
| Organizations that are unwilling or unable to incorporate code review into | ||
| their software development practices. |
There was a problem hiding this comment.
I'm wondering whether this shouldn't be stronger and say "enforce" rather than "incorporate":
Suggested change
| Organizations that are unwilling or unable to incorporate code review into | |
| their software development practices. | |
| Organizations that are unwilling or unable to enforce code review into | |
| their software development practices. |
| - Retained History: The revision and its change history are preserved | ||
| indefinitely and cannot be deleted, except when subject to an established | ||
| and transparent policy for obliteration, such as a legal or policy | ||
| requirement. In that later case, a justification should be emitted in |
There was a problem hiding this comment.
Suggested change
| requirement. In that later case, a justification should be emitted in | |
| requirement. In that later case, a justification SHOULD be emitted in |
Comment on lines
+343
to
+346
| Attributes changes in the version history to specific actors and timestamps, | ||
| which allows for post-auditing, incident response, and deterrence for bad | ||
| actors. Strong authentication makes account compromise more difficult, | ||
| further ensuring the integrity of change attribution. |
There was a problem hiding this comment.
I think these are 2 different benefits that should be split according to the respective requirements:
Suggested change
| Attributes changes in the version history to specific actors and timestamps, | |
| which allows for post-auditing, incident response, and deterrence for bad | |
| actors. Strong authentication makes account compromise more difficult, | |
| further ensuring the integrity of change attribution. | |
| - Strong authentication makes account compromise more difficult, | |
| further ensuring the integrity of change attribution. | |
| - Attributes changes in the version history to specific actors and timestamps, | |
| which allows for post-auditing, incident response, and deterrence for bad | |
| actors. |
Comment on lines
+371
to
+373
| decision about what they’re approving. The reviewer MUST be presented with | ||
| a full, meaningful content diff between the proposed revision and the | ||
| previously reviewed revision. For example, it is not sufficient to just |
There was a problem hiding this comment.
For the MUST to make sense in terms of compliance the reviewer cannot be the subject. This sentence needs to be reversed:
Suggested change
| decision about what they’re approving. The reviewer MUST be presented with | |
| a full, meaningful content diff between the proposed revision and the | |
| previously reviewed revision. For example, it is not sufficient to just | |
| decision about what they’re approving. A full, meaningful content diff between | |
| the proposed revision and the previously reviewed revision MUST be | |
| presented to the reviewer. For example, it is not sufficient to just |
Comment on lines
+380
to
+382
| Since all changes have been agreed to by at least two distinct trusted | ||
| entities, a compromise of a single entity does not result in compromise | ||
| of the project. |
There was a problem hiding this comment.
Suggested change
| Since all changes have been agreed to by at least two distinct trusted | |
| entities, a compromise of a single entity does not result in compromise | |
| of the project. | |
| Since all changes have to be agreed to by at least two distinct trusted | |
| entities, a compromise of a single entity is not sufficient to compromise | |
| the project. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Draft a the new source track level