pull_request runs workflow logic in the context of a pull request and is generally safer for untrusted contributions. pull_request_target runs with the permissions and secrets of the base repository, which can be useful for controlled review workflows but is much riskier if forked content can influence execution. The key distinction is whether untrusted code can touch privileged context.
Why CI/CD event context changes the security boundary
The difference between these two GitHub Actions triggers is not just where a workflow starts, but whose trust boundary it inherits. With OWASP Non-Human Identity Top 10, the important lesson is that secrets, tokens, and workflow permissions must be treated as identities with scope, not as convenient configuration. The trigger choice determines whether untrusted pull request content can influence a job that also has repository-level authority.
That matters because CI/CD pipelines frequently combine code execution, artifact publishing, and privileged credentials in one automation path. A workflow that is safe for untrusted contributions can become unsafe when the same code path is allowed to act with base-branch permissions, especially if it can read secrets, write comments, or publish build outputs. In practice, many security teams encounter the danger only after a benign review workflow is reused for a trusted maintainer action and the event boundary is no longer obvious.
How the two triggers behave differently in a real pipeline
pull_request is designed for validating proposed changes. It is usually the better choice when the workflow needs to test code from forks or other untrusted sources, because it is easier to keep the job in a lower-trust context. The practical security benefit is simple: the pipeline can fail safely if the change is malicious or broken, without automatically granting that code access to privileged repository secrets.
pull_request_target is different because it executes in the context of the base repository. That makes it useful for certain review automation tasks, such as labeling, triage, or controlled checks that need repository metadata and approved permissions. The risk is that maintainers can accidentally wire the workflow so that content from the pull request influences commands, file paths, or scripts that run with elevated authority.
Security teams should think about three separate questions:
- Can the workflow read secrets or write protected resources?
- Can untrusted pull request content change what gets executed?
- Is the workflow meant to validate code, or only to act on the pull request metadata?
If the answer to the second question is yes and the first answer is also yes, the design is usually unsafe. The safest pattern is to keep validation and privileged review actions separate so that a forked contribution never inherits more authority than the task requires. This guidance breaks down when teams mix review automation, artifact handling, and deployment logic in the same workflow path.
Where the usual guidance fails and the trade-offs start
Tighter workflow isolation often increases operational overhead, requiring teams to balance safer defaults against the convenience of single-file automation. That trade-off is real when a repository needs both low-trust validation and privileged maintainer actions, because the simplest configuration is not always the safest one.
One common edge case is a workflow that needs to comment on a pull request, update labels, or collect status data. Those tasks may seem harmless, but if the same job also checks out code or evaluates script content from the branch, the privileged context becomes dangerous. Another edge case is secrets that are not obviously sensitive, such as tokens used for package publishing, dependency scanning, or internal API access; these still widen blast radius if exposed.
There is no consensus shortcut that makes pull_request_target broadly safe for forked code. The safer interpretation is to reserve it for metadata-driven actions and keep any execution of untrusted source in a lower-privilege workflow. The control fails when teams assume the event name itself provides protection rather than verifying what the job actually runs and what identity it inherits.
Risk and Threat Considerations
The material risk is privilege escalation through untrusted workflow input. A pull request from a fork can become a delivery mechanism for command injection, secret exposure, or unauthorized repository actions if the workflow runs with base-repository authority and consumes attacker-influenced content.
Failure mechanism: The attacker does not need to break GitHub Actions itself. They only need a workflow that combines trusted permissions with untrusted data, such as checkout, shell execution, templating, artifact handling, or script evaluation. Once that happens, the privileged job can be steered into reading secrets, modifying outputs, or performing actions that were intended only for maintainers.
Impact: The likely consequences are secret compromise, tampered build outputs, polluted release artifacts, unauthorized comments or labels, and in worse cases downstream supply-chain compromise if a poisoned workflow publishes or promotes a malicious build.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | CI/CD triggers control secret exposure through workflow identity and token scope. |
| Recommendation — Restrict secret access to trusted workflow contexts and separate untrusted PR validation from privileged automation. | ||
| CIS Controls v8 | 6.3 — Access Control Management | The question turns on who can execute privileged actions and under what trust boundary. |
| Recommendation — Limit workflow permissions so untrusted pull requests cannot act with repository-level authority. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Forked PR workflows can expose an attacker-controlled path into privileged automation. |
| Recommendation — Review CI/CD entry points for injection paths that let untrusted input reach privileged execution. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions | The trigger choice determines which identities and permissions the job inherits. |
| Recommendation — Enforce least privilege so workflow permissions match the trust level of the triggering event. | ||
Practitioner Guidance
What to prioritise: Treat event choice as an access-control decision, not a workflow convenience decision. The first question is whether the job needs privilege at all; if it does not, keep it in the lower-trust path and remove secrets and write permissions by default.
Decision rule: Use the safer trigger for validation of untrusted contribution content, and reserve the privileged trigger for metadata-only or maintainer-controlled actions. If the workflow must both inspect untrusted code and use repository authority, split it into separate jobs or separate workflows rather than hoping review discipline will catch every path.
What to verify: Confirm that any privileged job cannot be influenced by attacker-controlled filenames, scripts, command arguments, or generated files. Verify the effective permissions of the token in the exact event context, not the permissions you expected from the repository settings.
Practitioner takeaway: The real security boundary is not the pull request itself, but whether untrusted content can influence a job that has trusted identity and secrets. If that linkage exists, the workflow design should be treated as a privilege-escalation risk until proven otherwise.
Related resources from NHI Mgmt Group
- What is the difference between continuous pentesting and standard CI/CD security scanning?
- What is the difference between pipelineless AppSec and traditional CI/CD security scanning?
- What is the difference between point tools and a platform approach for CI/CD security?
- What is the difference between CI/CD security assessment and runtime guardrails for AI applications?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
