Thank you for all that work; it is much appreciated from the security
team's point of view.
Also if I may suggest - I have been successfully using workflow_run and
"signal/worker" pattern to trigger actions based on comments or on
rebase/update/push to a PR.
This pattern is far easier to get right from the security standpoint (make
sure you never check out the code and never read any description /title
(interpolation on bash etc.) from Pull request - only read numeric ids via
GH APIs.
And only read the content of comments made by maintainers or artifacts
generated by the PR.
That works pretty nicely and is much harder to shoot yourself in the foot.
And you can even add some heuristics to check if there are no.aualocious
things being done in those workflows.
A good example is what I've done for "magpie-site" building - where
maintainer can comment on the PR ("/show-preview") - and it triggers a
workflow that publishes preview of the site and allows to select part of
the site, take screenshot and comment directly on the PR:
* Trigger/Signal:
https://github.com/apache/magpie-site/blob/main/.github/workflows/preview-signal.yml
.
* Build and Deploy:
https://github.com/apache/magpie-site/blob/main/.github/workflows/build.yml
* Publisher:
https://github.com/apache/magpie-site/blob/main/.github/workflows/preview-publish.yml
J.
On Fri, Oct 2, 2026, 18:22 Kenneth Knowles <[email protected]> wrote:
> Makes sense & thanks for handling this.
>
> I would particularly highlight the possible workflow change:
>
> The "standard" workflow* of maintaining branches on your own fork and
> opening a PR to the main fork is now at a slight disadvantage. Committers
> will benefit, at least slightly, from opening branches on the main repo.
>
> I don't intend to change my workflow (yet), but will take some time to
> evaluate how much it matters, and expecting that we will continue to
> improve the situation. If I understand correctly, self-hosted runners +
> pull_request trigger will still be able to run cloud-based ITs.
>
> Kenn
>
> *I checked the last 20+ PRs I reviewed and they all used this workflow,
> even though almost all of them were from committers and PMC.
>
> On Fri, Oct 2, 2026 at 6:33 AM Danny McCormick via dev <
> [email protected]> wrote:
>
>> Hey everyone, as part of a security hardening effort, I recently moved
>> most of our GitHub Actions workflows from the pull_request_target trigger
>> to the pull_request trigger (example PR moving some workflows -
>> https://github.com/apache/beam/pull/40360).
>>
>> *Expected Impact*
>>
>> The expected impact of this change should be relatively small, but there
>> is some loss/change of functionality:
>>
>> 1. Pull requests created from forks (as opposed to branches on the
>> apache/beam repo) will not have access to workflow secrets. For a few
>> workflows, this means a couple of tests will be skipped. For all workflows,
>> this means that they will not be able to write back to the build cache.
>> They should still be able to read from the build cache.
>> 2. Using comments to trigger workflow reruns will no longer work. I have
>> not seen much use of this functionality in a while anyways.
>> 3. Workflows from non-committers may need to be manually approved more
>> often before running.
>>
>> If you see impacts outside of this, please let me know.
>>
>> *Why this change now (feel free to ignore this section if you don't care
>> about the rationale)*
>>
>> While there were no known exploits in our previous CI infrastructure,
>> pull_request_target was drawing a lot of security reports and did open us
>> up to higher potential for an accidental security bug. In fact, the feature
>> is considered risky even by GitHub and they are intentionally
>> reducing/restricting its usage.
>> https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target
>> has
>> more details. The Beam PMC was having a hard time staying on top of these
>> reports, and this should simplify the associated toil while reducing our
>> overall risk profile.
>>
>> At the same time, some of the problems that the pull_request_target
>> functionality was originally introduced to solve are less relevant - for
>> example, as a repo we are much less reliant on secrets than we used to be.
>> Given the relatively small impact of the change, now seemed like a good
>> time to make the move.
>>
>> Please let me know if you have any questions or concerns.
>>
>> Thanks,
>> Danny
>>
>
