Untrusted pull requests should not run with the same privileges as trusted internal builds. Organisations should require manual approval where possible, disable automatic builds for unknown contributors, and remove access to deployment credentials, sensitive repositories, and other high-risk secrets. If external code must be tested, run it in an isolated environment with tightly constrained permissions.
Why This Matters for Security Teams
Untrusted pull requests are a supply chain control problem, not just a build queue problem. The risk is that code from an unknown or compromised contributor can influence tests, logs, environment variables, artifacts, or downstream deployments before a reviewer has validated what it actually does. That creates a direct path to secret exposure, token misuse, and tampering with release integrity.
For security teams, the key issue is privilege separation. A CI/CD system that treats external contributions the same as internal branches is effectively giving outside code access to the organisation’s build trust boundary. That boundary should be explicit: who can trigger a build, what data the job can read, what credentials it can reach, and where the resulting artifacts can go. The NIST Cybersecurity Framework 2.0 is useful here because it pushes teams to define governance, protect assets, and reduce blast radius rather than relying on developer intent alone.
Practitioners often miss that “just running tests” can still execute arbitrary code with access to repository contents, build metadata, or cloud identities attached to the runner. In practice, many security teams encounter CI/CD compromise only after secrets have already been exposed through a seemingly routine pull request build, rather than through intentional review of pipeline trust boundaries.
How It Works in Practice
The operational pattern is straightforward: separate untrusted builds from trusted builds, then strip the untrusted path of anything that would increase impact if the code is malicious. That usually means a distinct pipeline or job template for external contributions, no automatic access to production-like credentials, and restricted read access to only the minimal source material required to compile or test the code.
Where possible, untrusted pull requests should require human approval before execution. If automated validation is necessary, the build should run in an isolated environment with short-lived identities, no persistent workspace, and no direct route to deployment systems. Secrets should be injected only when absolutely required, and ideally not at all for external contributions. Build logs, caches, and artifact stores also need review, because sensitive data can leak there even when the job itself is denied obvious secret variables.
Teams usually need to make a few implementation choices explicit:
- Use separate runners or isolated sandboxes for external contributions.
- Disable automatic deployment and release promotion from untrusted jobs.
- Scope repository permissions so the job can read only what it needs.
- Prefer ephemeral credentials over long-lived tokens or shared service accounts.
- Review artifact handling, cache reuse, and log redaction as part of the same control.
This becomes especially important when the CI/CD system has broad network reach, shared runners, or inherited cloud permissions, because the build environment can then pivot into secrets, internal services, or other repositories with very little friction. These controls tend to break down when shared runners retain stale credentials or when pipeline templates allow unreviewed changes to modify execution context.
Common Variations and Edge Cases
Tighter isolation often increases build time, maintenance effort, and developer friction, so organisations have to balance delivery speed against the consequence of letting external code execute with internal trust. There is no universal standard for every repository, but current guidance suggests risk-based separation: the more sensitive the project, the stronger the controls around untrusted contributions.
One common edge case is open-source contribution workflows, where maintainers want to test community patches without exposing internal secrets. In that model, best practice is evolving toward “build with minimal trust, then validate with privileged steps only after review.” Another is monorepo CI, where trusted and untrusted code paths share infrastructure. In those environments, the safest approach is to treat the pull request build as hostile until proven otherwise, even if it originates from a known employee account.
Identity matters here too. A pipeline should not assume that a GitHub or GitLab account is equivalent to trustworthy execution authority. Human identity, repository permission, and runtime privilege are separate controls, and they should not be collapsed into one. Organisations that blur those layers usually discover the problem when a contributor or dependency update has already reached a protected branch or internal secret store.
For broader governance, teams can map this pattern to secure build policy, artifact integrity, and access review discipline, then keep the operational rule simple: untrusted code may be tested, but it should never inherit the privileges of trusted code.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | CI/CD jobs need least-privilege access and separate trust boundaries. |
| MITRE ATT&CK | T1195 | Malicious pull requests can be a software supply chain infection path. |
| OWASP Agentic AI Top 10 | A01 | Unsafe tool execution patterns mirror broader untrusted code execution risks. |
| NIST Zero Trust (SP 800-207) | SC | Zero trust principles support isolating untrusted CI jobs from internal resources. |
Limit untrusted builds to minimal permissions and separate them from privileged release workflows.
