Update BR-01 to split CI/CD security into 3 areas

[evankanderson]

As discussed in the 2025-11-25 meeting and on Slack.

The BR-01 controls was originally lifted from the Scorecard Dangerous-Workflow check. When this control was refactored into assessment criteria, we ended up with some ambiguity and possible overlap:

• BR-01.01 talked about "input parameters", which suggests something like the GitHub workflow_run trigger, which supports user-selected explicit values. It could also be read to cover input metadata (e.g. PR title), but it's not clear.
• BR-01.02 talked about specifically sanitizing branch names, but not other input metadata.

I unified the current assessments into BR-01.01, which covers all untrusted metadata executed without contributor review.

Both of these missed the "Untrusted Code Checkout" check from Dangerous-Workflow, which I've revived as BR-01.03 (to avoid re-using BR-01.02 with a different meaning).

I revised the plain meaning of BR-01.01 to BR-01.04 as a level 3 control for projects with higher levels of assurances.

[funnelfiasco]

This seems significant enough that I'm going to leave a fake nack to block merging in order to make sure there's enough time for discussion.

[SecurityCRob]

I'm fine adding more requirement statements, as Evan requests here. I ask that changes like this get merged into the crosswalk spreadsheet as we implement them, as some stakeholders use that as a prime source. I think we have the yaml --> website covered through our automation. We want to ensure all paths into the catalog are consistent for the user.

[evankanderson]

I'm fine adding more requirement statements, as Evan requests here. I ask that changes like this get merged into the crosswalk spreadsheet as we implement them, as some stakeholders use that as a prime source. I think we have the yaml --> website covered through our automation. We want to ensure all paths into the catalog are consistent for the user.

You're talking about filling in the Scorecard -> Dangerous Workflows mapping for BR-01? And you want me to update docs/Compliance%20Crosswalk%20Matrix-17Nov2025.xlsx, or something else (possibly not in source control)?

[SecurityCRob]

I'm fine adding more requirement statements, as Evan requests here. I ask that changes like this get merged into the crosswalk spreadsheet as we implement them, as some stakeholders use that as a prime source. I think we have the yaml --> website covered through our automation. We want to ensure all paths into the catalog are consistent for the user.

You're talking about filling in the Scorecard -> Dangerous Workflows mapping for BR-01? And you want me to update docs/Compliance%20Crosswalk%20Matrix-17Nov2025.xlsx, or something else (possibly not in source control)?

No, our Compliance Crosswalk(1) - after each update of the yaml files I've been trying to keep it current. Beyond the yaml files, if we had some way to get this file into git and still allow edits, that would be a dream. As it goes today after I update the xls, i output a pdf and store in our osps repo.

(1) - https://docs.google.com/spreadsheets/d/1an5mx3rayoz3JRFUepD56zgprpwXBXBG70fVZvIMCpA/edit?gid=1342785291#gid=1342785291

[funnelfiasco]

@evankanderson can you please address Eddie's feedback?

[evankanderson]

@evankanderson can you please address Eddie's feedback?

Addressed, I think.

[evankanderson]

We need to mark this as removed or retired, remove the applicability items, and change the text to say Retired in https://github.com/ossf/security-baseline/pull/443.

[evankanderson]

This now renders as:

$ grep -B 1 -A 6 -h BR-01.02 docs/versions/devel*

#### OSPS-BR-01.02

Retired in https://github.com/ossf/security-baseline/pull/443


#### OSPS-BR-01.03

In devel.md, and does not show up at all in devel-checklist.md.

[funnelfiasco]

@evankanderson I think I'm good with shipping this once you apply the suggestions you noted a couple of weeks ago.

[evankanderson]

I also added some more validation on the applicability (and assessment id) field -- the rules are:

• If "retired" is used, then it is the only allowed applicability, and the text must read "Retired in ..."
• Otherwise, the "Maturity Level X" numbering must start at the lowest level, and must include each higher maturity level in order.
• Assessment IDs may not be repeated (including across different controls)

There's probably more validation that could be done, but I didn't want to make this PR 80% Go code.

[evankanderson]

This now renders as:

$ grep -B 1 -A 6 -h BR-01.02 docs/versions/devel*

#### OSPS-BR-01.02

Retired in https://github.com/ossf/security-baseline/pull/443


#### OSPS-BR-01.03

In devel.md, and does not show up at all in devel-checklist.md.

[evankanderson]

Note that a applicability: ["retired"] is the best we can do with current Gemara, but see also this discussion with @eddie-knight and @jpower432 on #gemara in Slack