Only with extreme caution. pull_request_target can expose secrets and higher-privilege repository context to workflow code if the workflow itself is modified or abused. For dependency automation, the safer pattern is to minimise privileged triggers, pin reusable workflows carefully, and keep secret-bearing jobs separate from untrusted code execution.
Why This Matters for Security Teams
For automated dependency workflows, pull_request_target is not just another CI trigger. It runs in the context of the base repository, so a small workflow change can turn a routine update into secret exposure, token abuse, or privilege escalation. That risk matters because dependency automation often touches the same paths that hold release credentials, signing keys, and deployment access. NHI Management Group research shows that 96% of organisations store secrets outside secrets managers in vulnerable places such as code, config files, and CI/CD tools, which makes workflow trust boundaries especially fragile. The NIST Cybersecurity Framework 2.0 reinforces the need to protect identity, access, and execution context as separate concerns.
Security teams often assume the dependency bot is the only thing being trusted, when the real issue is whether the workflow definition itself can be influenced by untrusted code. That distinction is where many pipelines fail. A dependency automation flow should be treated as privileged automation, not as a convenience feature. In practice, many security teams encounter secret leakage only after a workflow has already been modified to run with elevated repository context, rather than through intentional review of the trigger model.
How It Works in Practice
The safest pattern is to minimise privileged triggers and separate untrusted analysis from secret-bearing actions. For dependency automation, that usually means running validation on the pull request with no write access, then moving any merge, publish, or release step into a protected job that only executes after review or on trusted branches. When reusable workflows are involved, pin them to immutable references and review them as production code. The same logic applies to tokens: short-lived, scoped credentials are far safer than long-lived secrets exposed to a broad workflow context. This is consistent with the guidance in NIST Cybersecurity Framework 2.0, which prioritises access control and protective measures tied to risk.
For organisations handling supply chain sensitive automation, NHI telemetry should be part of the review loop. NHIMG’s LiteLLM PyPI package breach is a useful reminder that dependency paths can become credential theft paths when build trust is too broad. A practical workflow usually includes:
- Using pull_request for untrusted dependency updates and reserving privileged jobs for post-review execution.
- Separating secret access from code execution so the workflow that tests changes cannot also publish or deploy.
- Pinning reusable workflows and third-party actions to commit SHAs, then reviewing updates deliberately.
- Issuing the smallest possible token scope for the shortest possible time.
Where organisations need stronger governance, pair repository policy with identity controls and runtime checks. The broader NHI guidance in LiteLLM PyPI package breach shows how quickly credential exposure compounds when automation is allowed to self-modify. These controls tend to break down in monorepos with shared workflows and many maintainers because a single mis-scoped token can reach multiple deployment paths at once.
Common Variations and Edge Cases
Tighter workflow control often increases developer friction and release latency, requiring organisations to balance speed against privilege reduction. That tradeoff is real, especially where dependency updates are frequent and automated merging is part of the delivery model. There is no universal standard for when pull_request_target is acceptable, but current guidance suggests it should be reserved for narrow cases where the workflow file is fully trusted, the job has no secret exposure to untrusted code, and the risk of repository-context escalation is explicitly accepted.
One common exception is documentation-only automation or metadata updates that do not touch build logic, secret material, or deployment paths. Even then, teams should prefer defensive patterns such as read-only validation, protected environments, and separate promotion steps. Another edge case is vendor-managed reusable workflows: these can reduce local complexity, but only if the calling repository treats the reusable workflow as a controlled dependency and pins it carefully. The NIST Cybersecurity Framework 2.0 is helpful here because it frames this as a governance problem, not just a pipeline configuration issue. In practice, approval gates and branch protections help, but they do not compensate for a workflow that hands secret-bearing context to code that should not see it in the first place.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers secret handling and credential exposure in automated workflows. |
| NIST CSF 2.0 | PR.AC-4 | Directly supports least-privilege access for CI/CD and repository automation. |
| NIST AI RMF | Useful for governance of automated decision paths and operational accountability. |
Define ownership, review, and risk acceptance for any automation that can trigger privileged actions.
