Clarify OSPS-BR-01 to better express the intent

[funnelfiasco]

This is my own attempt at #63. It differs from @david-a-wheeler's #103 by:

• Keeping the criterion inclusive of build pipelines.
• Explicitly calling out that we do not mean to prohibit the use of RPM, deb, etc.

It does include some edits from David's PR as well.

[funnelfiasco]

Commentary on the "build and release" versus "release + build in certain cases":

As I think about it, beyond the concern with "does 'release and can read secret data' sufficiently cover all of the things we're trying to guard against?" that I raised in my comment on #103, I am also worried about the cognitive load that a more narrowly-carved criterion might create.

I'm sympathetic to the argument David made in today's meeting about having a solid justification for adding a criterion. In this particular case, though, I worry that trying to figure out exactly where the boundary is will distract maintainers from taking the action necessary to secure their workflows. As noted on the call by someone, most builds don't get released, but my hunch is that most build workflows could lead to a release, so there's not a lot of benefit in saying "if you have a build workflow that you know will never lead to a release, you can run whatever you want on it and we don't care". Or at least the benefit of not caring doesn't outweigh the added complexity.

[evankanderson]

I've been struggling a bit with how to validate this criteria (as writ, it seems to require avoiding security bugs in writing release software -- I assume this is aspirational, but it doesn't provide a clear "you are done" threshold for either project authors or validation software).

[evankanderson]

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?

[funnelfiasco]

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".

[david-a-wheeler]

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.

[evankanderson]

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

[funnelfiasco]

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.

[evankanderson]

Additionally, the scorecard check is more about workflows that run on PR, rather than on project build.

I think both are important, but the reference to the scorecard check here is confusing.