thomasnordquist
commented
2 months ago Hey there, sorry for taking my time to respond, and feel free to contradict me if you think I am wrong. A proof-of-concept for an attack is also very welcome.
Securing secrets is hard
- Using
pull_request_targetallows to limit the context of actions to "protected" branches (main,release). (workflows of target branches are used) - Workflows can only be updated via a PR with a Codeowner as reviewer (Me)
- Workflow segregation: Secrets may only be used in steps where no code/tools maintained in this PR are used. (external actions)
- this is what makes it safe to use
pull_request_target
- this is what makes it safe to use
- forks cannot run github actions in context of this repo without a maintainer approving the run. Workflow segregation still protects grabbing secrets
Given a good reason, I might consider using pull_request over pull_request_target, this will however weaken the security in regard to maintainers.
Make workflow run workflow in source repo context to prevent secrets exposure.
pull_request_targetevent will be run in target repo context and will have access to secretspull_request_targetevent SHA is latests commit in target base branch, and running ui-tests here does not make sense as ui-tests will be run on latest commit in target branch.