Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify OSPS-BR-01 to better express the intent #104

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Clarify OSPS-BR-01 to better express the intent #104

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5a0fe20
Clarify OSPS-BR-01 to better express the intent
funnelfiasco Dec 10, 2024
0d3b3b5
Improve wording
funnelfiasco Dec 20, 2024
b2fe9d8
Update baseline.yaml
funnelfiasco Dec 20, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 12 additions & 6 deletions baseline.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -196,18 +196,24 @@ criteria:
maturity_level: 1
category: Build & Release
criteria: |
The project's build and release pipelines
MUST NOT execute arbitrary code that is
input from outside of the build script.
Build and release pipelines MUST only execute
code that's present in the repository *or* from external trusted sources.
funnelfiasco marked this conversation as resolved.
Show resolved Hide resolved
objective: |
Reduce the risk of code injection or other
security vulnerabilities in the project's
build and release processes by restricting
the execution of external code.
the execution of external code in workflows.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what "in workflows" here is supposed to capture compared with the older version.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is to scope it specifically to build and release workflows as opposed to, say, the user execution of the program. Since it's in the "Build and Release" category, I'd accept an argument that it is redundant.

implementation: |
Ensure that the project's build and release
pipelines do not execute arbitrary code
provided from external sources.
pipelines do not execute untrusted code
provided from external sources. Maintainers
may establish trust in a variety of ways,
including digital signature verification and
SecurityCRob marked this conversation as resolved.
Show resolved Hide resolved
inspection of external code. For clarity,
this criterion does not prohibit the use of
software in a package format that executes
scripts (e.g. RPM, .deb) so long as the
package itself is trusted.
Comment on lines 207 to +216
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm struggling with how to enforce this. For example, does this prohibit using a tool built and maintained in the same repository which automates some of the release steps unless we can ensure that the tool cannot be subverted? As written, it suggests every Makefile and data processor needs a security review, which seems high for maturity level 1.

Similarly, it's not clear whether this criteria establishes a transitive duty of care to audit not just your own codebase, but those of pipeline dependencies (e.g., do I need to check on untrusted code execution from actions/setup-go in my GitHub workflows)? Or can I say "I'm using this action from $ELSEWHERE, I assume it's secure" at level 1, and have additional security criteria at level 2 or 3?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does not establish a transitive duty of care. As an example, a workflow that uses an Ubuntu image from Canonical wouldn't violate this because it's a trusted source. A workflow that uses some-random-rebuild/ubuntu-latest would, unless the project has established trust in the some-random-rebuild project. The idea is more along the lines of "we're getting the code we think we're getting" as opposed to "we have inspected every line of software all the way down and it is clean".

For the first part, I would say if it's in the same repository, it's part of the project and therefore not an "external source".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As an example, a workflow that uses an Ubuntu image from Canonical wouldn't violate this because it's a trusted source.

But it would violate this requirement as written. The term "trusted source" isn't present in this text.

I'll try to make a change, I think the point is that build only runs code in the repo or from external trusted sources.

control_mappings: # TODO
scorecard_probe:
- hasDangerousWorkflowScriptInjection
Expand Down
Loading