The pull_request_target should not be used with a checkout as can be seen in the following warning from the Github Documentation Page:
Reproduction steps
None
Expected vs. actual results
Analysing the workflow and looking at the more secure alternatives, I could think in two approaches:
Use pull_request
Instead of using pull_request_target, we could use the pull_request which would change the current behavior in two ways:
The verifications would be done in a "merge commit"
The workflow would not be granted the read-all and write-all permission that make it dangerous.
EDIT: Create a workflow with a workflow_run trigger in another workflow to add the comment
Use label verification
We can use a type: [labeled] and a condition of if: ${{ github.event.label.name == 'is ok to test' }} to check for a label "is ok to test" for example, that you would manually add once you saw that nothing potentially dangerous would be running.
That's the two solutions I though, but let me know if you know another one we can explore. I can open a PR with any solution we agree on this issue.
Minimal code example
No response
Error messages
No response
Compiler and operating system
None
Library version
None
Validation
[ ] The bug also occurs if the latest version from the develop branch is used.
nlohmann
commented
1 year ago
Description
Hi, I am Joyce working on behalf of Google and the OpenSSF.
The project has one workflow with dangerous or risky behavior (identified by using the Scorecard tool), which is the https://github.com/nlohmann/json/blob/develop/.github/workflows/check_amalgamation.yml.
The pull_request_target should not be used with a checkout as can be seen in the following warning from the Github Documentation Page:
Reproduction steps
None
Expected vs. actual results
Analysing the workflow and looking at the more secure alternatives, I could think in two approaches:
Use
pull_requestInstead of using
pull_request_target, we could use thepull_requestwhich would change the current behavior in two ways:Use label verification
We can use a
type: [labeled]and a condition ofif: ${{ github.event.label.name == 'is ok to test' }}to check for a label "is ok to test" for example, that you would manually add once you saw that nothing potentially dangerous would be running.That's the two solutions I though, but let me know if you know another one we can explore. I can open a PR with any solution we agree on this issue.
Minimal code example
No response
Error messages
No response
Compiler and operating system
None
Library version
None
Validation
developbranch is used.