Skip to content

Commit

Permalink
content: draft: reword "Change management process" requirement (#1206)
Browse files Browse the repository at this point in the history
fixes #1139

Per #1139, 'documented process' was somewhat confusing and could be
interpreted as meaning some _prose_ documentation. I think the real aim
is to ensure all the rules for making a change to a branch were
followed.

So I changed the text to talk about those rules, rather than 'documented
process'. I think this is more aligned with what we're looking for?

---------

Signed-off-by: Tom Hennen <[email protected]>
  • Loading branch information
TomHennen authored Oct 24, 2024
1 parent adbc0b1 commit 8bd9129
Showing 1 changed file with 13 additions and 7 deletions.
20 changes: 13 additions & 7 deletions docs/spec/draft/source-requirements.md
Original file line number Diff line number Diff line change
Expand Up @@ -218,21 +218,27 @@ If a consumer is authorized to access source on a particular branch, they MUST b

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="change-management-process"><td>Change management process<td>
<tr id="change-management-process"><td>Enforced change management process<td>

The SCS MUST ensure that all technical controls governing changes to a [branch](#definitions)

1. Are discoverable by authorized users of the repo.
2. Cannot be bypassed except via the [Safe Expunging Process](#safe-expunging-process).

For example, this could be accomplished by:

The repo must define how the content of a [branch](#definitions) is allowed to change.
This is typically done via the configuration of branch protection rules.
It MUST NOT be possible to modify the content of a branch without following its documented process.
- Via the configuration of branch protection rules (e.g.[GitHub](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule), [GitLab](https://docs.gitlab.com/ee/user/project/repository/branches/protected.html)), or
- via application and verification of [gittuf](https://github.com/gittuf/gittuf) policies, or
- some other mechanism as enforced by the [Change management tool](#change-management-tool-requirements).

SLSA Source Level 2 ensures that all changes are recorded and attributable to an actor.
SLSA Source Level 3 ensures that the documented process was followed.
<td><td><td>✓
</table>

## 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.
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).

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

0 comments on commit 8bd9129

Please sign in to comment.