refactor: AC-04.01 control for clarity #396
Conversation
| project's version control system MUST default to the lowest available | ||
| permissions for all activities in the pipeline. | ||
| CI/CD system MUST default the task's permissions to the lowest | ||
| permissions granted in the pipeline. |
There was a problem hiding this comment.
Non blocking nit:
| permissions granted in the pipeline. | |
| permissions required by the task. |
There was a problem hiding this comment.
I like your suggestion but I think it does change the focus of the requirement from one in which the task's permissions are not configured/unspecified and therefore the task runs in the presumably more well defined and least privilege permission context of it's (the task's) enclosing pipeline to one in which the enclosing pipeline should more proactively try to understand the permission requirements of the task and assign only those.
There was a problem hiding this comment.
Are there CI/CD systems that use the highest permissions as a default? Or is the intent here to say "tasks should have read-only permissions unless explicitly granted more permissions at the task level"?
For example, if I have a github workflow that grants write at the top level of the workflow, would a job in that workflow that inherits write permission violate this control? Does the answer to that question depend on whether or not the job needs write permission?
If the answer is yes (or at least a conditional yes), maybe we're better off being more direct and saying "CI/CD tasks that require permissions beyond read must have permissions explicitly granted at every step" (except with better wording)
|
a65bd5d provides some historical context around prior intent |
Signed-off-by: Travis Truman <[email protected]>
This closes #395