Untrusted input never reaches a privileged context
Forge-supplied text such as an issue title, a branch name, or a commit message is written by whoever opened the contribution. Interpolated into a shell command it runs as code, and a workflow that builds a fork’s contribution while holding secrets hands those secrets to its author.
Observable check
on GitHub, no user-controlled ${{ github.event.* }} or ${{ github.head_ref }} expression appears inside a run: block, such values reach the shell through an env: block instead, and no pull_request_target or workflow_run workflow executes contributor-controlled code; on GitLab, user-controlled predefined variables are quoted when used in script:, no job evaluates them as generated shell, and every sensitive variable is masked with variable-reference expansion disabled.
Where this comes from
Last read against these sources on 2026-07-28.
Section 'Good practices for mitigating script injection attacks' gives the intermediate env: variable this rule requires, and the page also warns on pull_request_target with untrusted code. The GitLab half remains unsourced, and this is a checked negative rather than an unchecked gap: https://docs.gitlab.com/ci/pipeline_security/ covers secrets, variable masking, and image pinning, and says nothing about untrusted input reaching a job script.