What breaks when untrusted pull requests are allowed to run CI jobs before approval?

Allowing untrusted pull requests to run CI jobs can turn code review into remote code execution on internal infrastructure. If the build environment can reach privileged containers, shared nodes, or CI secrets, an attacker may escape the job boundary, harvest credentials, and pivot into release systems or cloud services. The safest pattern is to treat external code as hostile until it is explicitly approved and isolated.

Why the Pre-Approval CI Boundary Matters

When a pull request can run CI before approval, the CI system is no longer just validating code. It is executing attacker-controlled input inside an environment that may already be trusted by build tooling, artifact stores, package registries, and deployment automation. That boundary is where review stops being a passive check and becomes an execution path.

The practical issue is not only whether the job can fail, but what the job can reach. If the pipeline can talk to internal services, reuse shared runners, or expose secrets to the build step, the unapproved PR can inherit far more privilege than the reviewer intended.

How This Turns Into Infrastructure Exposure

Most CI abuse begins with the same basic pattern: untrusted code is executed in a context that has network reach, filesystem access, or injected credentials. From there, the attacker looks for job output leakage, filesystem traversal, environment variable disclosure, artifact poisoning, or a path out of the isolated runner.

If the CI job has access to cloud APIs, package signing keys, deployment tokens, or shared caches, the blast radius extends well beyond the repository. That is why pre-approval execution must be treated as an authorization decision, not just a developer convenience.

Controls such as least privilege, ephemeral execution, and strict separation between untrusted and trusted workflow stages matter because they reduce what a malicious PR can observe or reuse. Systems that cannot enforce that separation should assume the job is hostile and constrain it accordingly, as described in NIST SP 800-207 Zero Trust Architecture.

What Changes in Release and Secret Handling

Once a PR can run before approval, secrets handling becomes the critical control point. A build that receives long-lived credentials, signing material, or elevated service tokens can be used to exfiltrate those secrets directly or indirectly through logs, artifacts, network calls, or dependency hooks. The same job may also tamper with artifacts that downstream release stages trust.

That is why teams usually separate untrusted validation from privileged release actions, and why build provenance, artifact integrity, and controlled credential exposure are central to secure delivery. The relevant concern is not only whether the code compiles, but whether the CI stage can be trusted to keep its own outputs clean and its own inputs bounded.

For supply-chain control, SLSA is a useful reference for provenance and build integrity, while NIST SP 800-53 Rev 5 Security and Privacy Controls provides the broader access control, audit, and configuration management controls that support safer pipeline design.

Risk and Threat Considerations

Untrusted PR execution creates a direct attack path from repository contribution to internal execution. The main risks are credential theft, runner escape, cache or artifact poisoning, and unauthorized access to downstream systems that the CI environment can already reach.

Failure mechanism: The attacker embeds code that runs during the build, then uses CI privileges, environment variables, network access, or shared infrastructure trust to move from a review context into a trusted operational context.

Impact: Sensitive secrets can be exposed, internal systems can be touched from a trusted network location, and compromised build output can contaminate release pipelines or cloud services.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5, SLSA and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST Zero Trust (SP 800-207)	None — Zero Trust Architecture	Pre-approval CI needs strict trust boundaries and least-privilege execution.
Recommendation — Isolate untrusted PR jobs from trusted secrets and internal networks.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Untrusted builds should not inherit broader access than their job needs.
	AU-2 — Audit Events	CI abuse depends on detectable execution and secret-use events.
Recommendation — Restrict CI jobs to the minimum permissions required. Log untrusted job execution, secret access, and release-stage actions.
SLSA	None — Supply-chain Levels for Software Artifacts	Untrusted PR execution can poison build provenance and downstream artifacts.
Recommendation — Separate untrusted validation from trusted artifact signing and release.
NIST CSF 2.0	PR.AA-05 — Least Privilege	CI runners need constrained access paths to reduce blast radius from hostile PR code.
Recommendation — Limit CI service access to only the resources each stage requires.

Practitioner Guidance

What to verify: Confirm whether unapproved workflows can access secrets, internal networks, shared runners, or reusable caches. If any of those are true, treat the job boundary as part of your trust boundary and not as a harmless test environment.

Decision rule: If the PR is externally authored or otherwise untrusted, run it in a sandbox with no privileged secrets and minimal network reach. Reserve trusted credentials, signing steps, and deployment privileges for post-approval stages only.

Practitioner takeaway: The key question is not whether CI runs before approval, but whether untrusted code can influence anything that the rest of the delivery system already trusts.