A pull request is proposed code. A release workflow may hold permission to publish packages or deploy a service. When these two contexts meet, the pipeline has to preserve the distinction between a contribution awaiting review and code authorized to run with release privileges.
The relevant security question is which inputs a privileged job executes or trusts. That includes source files, build scripts, generated artifacts, and configuration supplied by earlier jobs.
The event determines an initial trust context
GitHub documents the security implications of pull_request_target, which uses the base repository's workflow context. Risk arises when that privileged context checks out and executes code from an untrusted pull request. The checkout alone is not the execution; a later build, test, or script invocation completes that path. GitHub's dedicated guidance explains the distinction.
An illustrative documentation repository uses automation to label contributions and another job to publish the site. Labeling does not require executing the contributor's build scripts. Keeping those responsibilities explicit makes the permissions needed by each job easier to inspect.
Follow artifacts as well as source checkout
A privileged job can consume an artifact produced by a less-trusted workflow. If it executes a script from that artifact or treats its contents as trusted deployment instructions, the boundary can be crossed without a direct source checkout in the release job.
Record where each artifact originated, which commit it represents, and how the consumer verifies that context. A filename or successful upstream status does not alone establish that the artifact came from an approved release revision.
Review permissions at the job level
Inspect repository-token permissions, environment secrets, deployment approvals, and network access. A test job may need to read source and upload results while a publishing job needs a narrower set of write operations. The review can identify permissions that are inherited broadly but used by only one task.
Also examine expressions that place issue titles, branch names, or other contributor-controlled text into scripts. The source of a string matters when a shell or interpreter processes it. Treating such values as data avoids confusing workflow metadata with executable instructions.
Validate with harmless fixtures
Use a controlled fork or test repository to submit a contribution that creates a harmless marker during its build. Confirm where the marker executes and whether that context has sensitive authority, without exposing or printing secrets. Test artifact acceptance using deliberately mismatched revisions.
The assessment record can show the route from event to job, inputs, credentials, and release output. A passing test demonstrates the reviewed boundary for the configured workflow. Changes to triggers, reusable workflows, runners, or artifact handling can alter that boundary and belong in later review.
Sources
GitHub Security Lab: Preventing Pwn Requests. The documentation repository and marker are illustrative test fixtures.
