One workflow can receive events with different trust levels
A museum maintains caption files in GitHub. Its workflow runs when volunteers open pull requests and when an editor starts a manual release check. Both runs can execute the same filename, but they should not receive the same access or perform the same side effects. GitHub sets GITHUB_EVENT_NAME to the event that triggered a workflow, such as pull_request or workflow_dispatch. This is a useful routing signal, not proof that the code being examined is trusted. The article describes an illustrative CI policy, not a tested repository or a guarantee that every branch protection rule has been met.
Read the event name in its proper context
GitHub documents GITHUB_EVENT_NAME as a default environment variable and github.event_name as the related workflow context property. Conditions evaluated by the workflow system can use the context before a runner step starts; a shell command uses the environment variable after the job is running. Keep those uses distinct. The event identifies how the workflow was triggered, not which commit is safe, which account should be approved, or whether a caption translation is correct. Treat ref names, payload strings, and pull-request titles as untrusted data even when GitHub provides the surrounding event metadata.
Separate pull-request checks from release activity
For a pull_request event, run format validation, caption file parsing, linting, and other checks that do not require publishing credentials. Use minimal repository permissions and do not expose secrets to code that can be modified by external contributors. For workflow_dispatch, require the established editorial release process and verify the selected ref and expected repository before acting. An event-name condition can choose which job to attempt, but it is not a substitute for environment approvals, token scopes, protected branches, or human sign-off. Put those safeguards in the platform and release workflow independently.
Understand the pull_request_target boundary
GitHub warns that pull_request_target has elevated trust compared with ordinary pull_request execution and must not casually check out or execute code from an untrusted pull request with repository secrets or a privileged token. GitHub’s current security guidance also describes changes to default event policy for public repositories, including a scheduled enforcement date. Review that notice for the repository’s actual settings. If a workflow only needs to read changed caption text, prefer an unprivileged inspection path. Do not use a simple GITHUB_EVENT_NAME string comparison to sanitize untrusted code or to approve a privileged checkout.
Construct a small event-routing matrix
Write down the expected events and permitted actions before editing YAML. For example, pull_request may run syntax checks and publish a neutral status result; push to an approved branch may run additional regression tests; workflow_dispatch may start a manual review path that still requires release authorization. The event matrix should name the source repository, checked-out ref policy, token permissions, and whether untrusted contributor files are executed or merely inspected. For a scheduled event, remember that the execution context can differ from a pull request and that a passing job is not evidence of caption accuracy.
Do not interpolate event payload into shell commands
An attacker can place unexpected characters in a branch name, issue title, or caption fixture. Even if the event is correctly identified, unsafe use of expressions in a shell script can create command-injection risks. Pass untrusted values through environment variables as data, quote shell parameters, and use structured tools rather than constructing commands from raw text. Avoid echoing entire event payloads or the github context into public logs because they may contain sensitive information. Prefer a parser that reads a known file path and validates content without executing it. A workflow trigger is an origin clue, not an input sanitizer.
Treat event, actor, ref, and run attempt separately
The event type answers what happened, while GITHUB_ACTOR identifies the original initiator, GITHUB_TRIGGERING_ACTOR can differ for re-runs, and ref variables describe which code line is involved. Those fields should be recorded separately when investigating a failed caption check. A manual rerun of a pull request is not transformed into an approved manual-release event, and GitHub documents that reruns use the privileges associated with the original actor. Keep the workflow run ID and attempt number in the audit ledger so later attempts do not overwrite earlier diagnostics. Do not infer permissions from the mere presence of a user name in logs.
Keep caption outputs and editorial approval apart
Automated checks can detect missing timestamps, invalid subtitle formats, unexpected language codes, and suspicious file paths. They cannot determine whether a translation accurately represents the speaker, whether sensitive testimony should be published, or whether an interview participant consented. Make release approval a separate authorized decision with a reviewed artifact and a link to the exact commit. Store only necessary diagnostic summaries in job artifacts. For sensitive recordings, restrict who can retrieve those artifacts and control how long they remain available. The comparison diagram shows different trust paths conceptually and should not be read as an actual security test.
Verify a safe gate using deliberately varied fixtures
Test ordinary pull requests, forked pull requests where applicable, a manual workflow run, a rerun, and a push to the protected branch in a controlled repository. Record which jobs are eligible to start and which require environment approvals. Inspect whether any untrusted content reaches a step with credentials, and check that passing CI never sets a publication flag by itself. If the event type is unexpected, the privileged path should not run. Review GitHub’s current event security guidance before deployment because repository policies and defaults may change. A secure workflow uses the event name as one input to a layered trust decision, not as its entire decision.
How We Research
We checked the current official documentation: GitHub default variables reference; GitHub event triggers reference; GitHub pull_request_target security guidance. We compared the feature contract and stated limitations with the specific hypothetical museum workflow in this article, separating technical behavior from policy, rights, consent, and business outcome. We did not run a live provider API test, inspect a production customer account, measure performance, or create the example outputs. All four illustrations are original explanatory diagrams rather than service screenshots or measured evidence. Verify version support, documentation updates, permissions, and applicable organizational policy before adopting the approach.
Frequently Asked Questions
It is GitHub’s default environment variable naming the event that triggered a workflow, such as pull_request or workflow_dispatch.
No. Verify the selected ref, permissions, environment approvals, and editorial sign-off separately.
No. Privileged workflows must avoid executing untrusted PR code with secrets or write-capable tokens.
They are related representations, but the github context is used in workflow expressions while the environment variable is available to runner steps.
No. Automated formatting checks cannot replace factual review, translation approval, or participant consent.