Clarify OSPS-BR-01 further #150
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
This attempts to clarify OSPS-BR-01 further. In particular, the term "arbitrary" currently used in the criterion doesn't really mean anything. Any sequence of bits could be "arbitrary". It doesn't matter if the bits are arbitrary or not. What matters is that the undesired inputs are *untrusted*. In fact, the *rationale* uses the term "untrusted", but the criterion and details aren't consistent with the rationale. I think that was what was meant anyway :-). Also: using "code execution" as a privileged resource is a terrible example. Any CI/CD pipeline does code execution, so expressly listing it here *confuses* things. Let's instead list "secret exfiltration" and "final release" as privileged operations. Those are *much* clearer as examples of things you should be concerned about :-). Not everyone has a separate "final release" step, and instead consider "merge to main" the same as final release. But even in that case, "merge to main" is a privileged operation that is not granted to everyone, so I think it still works. Signed-off-by: David A. Wheeler <[email protected]>
| to access privileged resources (code execution, | ||
| secret exfiltration, etc.) | ||
| to access privileged resources | ||
| (secret exfiltration, final release, etc.) | ||
| details: | | ||
| Ensure that any build and release pipeline actions |
There was a problem hiding this comment.
Suggested change
| Ensure that any build and release pipeline actions | |
| Ensure that any integration or release pipeline actions |
I feel like continuous integration (particularly pre-merge pipelines) are particular targets here. I feel like we should call them out explicitly.
Any suggestions? |
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.
This attempts to clarify OSPS-BR-01 further.
In particular, the term "arbitrary" currently used in the criterion doesn't really mean anything. Any sequence of bits could be "arbitrary". It doesn't matter if the bits are arbitrary or not.
What matters is that the undesired inputs are untrusted. In fact, the rationale uses the term "untrusted", but the criterion and details aren't consistent with the rationale. I think that was what was meant anyway :-).
Also: using "code execution" as a privileged resource is a terrible example. Any CI/CD pipeline does code execution, so expressly listing it here confuses things.
Let's instead list "secret exfiltration" and "final release" as privileged operations. Those are much clearer as examples of things you should be concerned about :-).
Not everyone has a separate "final release" step, and instead consider "merge to main" the same as final release. But even in that case, "merge to main" is a privileged operation that is not granted to everyone, so I think it still works.