Skip to content

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

Open
evankanderson wants to merge 6 commits intoossf:mainfrom
evankanderson:subdivide-ci;validation
Open

Update BR-01 to split CI/CD security into 3 areas#443
evankanderson wants to merge 6 commits intoossf:mainfrom
evankanderson:subdivide-ci;validation

Conversation

@evankanderson
Copy link
Contributor

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.

Copy link
Contributor

@funnelfiasco funnelfiasco left a comment

Choose a reason for hiding this comment

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

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
Copy link
Contributor

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
Copy link
Contributor Author

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)?

Comment on lines +93 to +94
CI/CD pipelines which accept collaborator input MUST sanitize and
validate that input prior to use in the pipeline.
Copy link
Contributor

Choose a reason for hiding this comment

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

This reads quite similar to the text removed above "When a CI/CD pipeline accepts an input parameter, that parameter MUST be sanitized and validated prior to use in the pipeline."

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This explicitly targets trusted-collaborator inputs to CI workflows, e.g. branch names in an explicitly-run GitHub workflow.

For that reason, it is Maturity Level 3 (protect project CI from insiders) compared with maturity level 1 (prevent drive-by pwning) of the other two requirements.

@SecurityCRob
Copy link
Contributor

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
Copy link
Contributor

@evankanderson can you please address Eddie's feedback?

@evankanderson
Copy link
Contributor Author

@evankanderson can you please address Eddie's feedback?

Addressed, I think.

@evankanderson evankanderson force-pushed the subdivide-ci;validation branch from e62baf2 to e22a781 Compare January 20, 2026 08:09
evankanderson and others added 5 commits January 20, 2026 00:10
Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>
Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>
…rusted.

Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>
* Add UKSSCOP reference-ids and claims to OSPS-DO.yaml

Dependent upon merge of ossf#426

DO mappings to UKSSCOP framework

Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com>

* Update baseline/OSPS-DO.yaml

Co-authored-by: Ben Cotton <ben@kusari.dev>
Signed-off-by: Travis Truman <trumant@gmail.com>

---------

Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com>
Signed-off-by: Travis Truman <trumant@gmail.com>
Co-authored-by: Travis Truman <trumant@gmail.com>
Co-authored-by: Ben Cotton <ben@kusari.dev>
Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>
Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>
@evankanderson evankanderson force-pushed the subdivide-ci;validation branch from e22a781 to 1526f46 Compare January 20, 2026 08:10
… subdivide-ci;validation

Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>
values) all collaborator inputs on explicit workflow executions.
While collaborators are generally trusted, manual inputs to a
workflow cannot be reviewed and could be abused by an account
takeover.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
takeover.
takeover or insider threat.

- Maturity Level 2
- Maturity Level 3
recommendation: # TODO
- id: OSPS-BR-01.02
Copy link
Contributor Author

Choose a reason for hiding this comment

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

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.

recommendation: |
CI/CD pipelines should sanitize (quote, escape or exit on expected
values) all metadata inputs which correspond to untrusted sources.
This includes data such as commit messages, tags, pull request titles,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Suggested change
This includes data such as commit messages, tags, pull request titles,
This includes data such as branch names, commit messages, tags, pull request titles,

@funnelfiasco
Copy link
Contributor

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

@funnelfiasco funnelfiasco self-requested a review February 6, 2026 19:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants