Untrusted Checkout

Expanded Definition

Untrusted checkout describes a CI/CD condition where workflow logic fetches source code that has not been fully trusted, then executes that code in a privileged automation context. In practice, this usually means a pull request, fork, or other external contribution is checked out on a runner that still has access to repository secrets, deployment tokens, or write permissions. The security issue is not the checkout step alone, but the combination of foreign code plus ambient privilege.

Within supply chain security, the term is closely associated with GitHub Actions style pipelines, but the pattern applies anywhere automated build or test infrastructure runs code from outside the trusted boundary. Guidance is still evolving across vendors, yet the core control objective is consistent with the NIST Cybersecurity Framework 2.0: reduce unnecessary access, isolate execution, and ensure code provenance is understood before trust is granted.

The most common misapplication is assuming that a pull request is “safe” because it only runs tests, which occurs when the workflow still exposes secrets, network reach, or write-capable credentials to the checked-out code.

Examples and Use Cases

Implementing untrusted checkout rigorously often introduces friction in developer workflows, requiring organisations to balance fast feedback for contributors against tighter isolation and reduced secret exposure.

• A public repository accepts a pull request from a fork, checks out the branch, and runs build steps without restricting token scope or secret access.
• An internal repository allows a lower-trust automation job to pull code from a feature branch, but the same job still has access to deployment credentials.
• A release pipeline uses unreviewed code from an external dependency mirror during validation, creating a path for attacker-controlled logic to reach the runner.
• A repository applies hardened workflow patterns such as separate validation jobs, restricted permissions, and secret-free linting before any privileged step runs. This aligns with broader secure automation guidance from sources such as NIST CSF 2.0.
• A security team blocks checkout of untrusted contributions in jobs that can publish artifacts, sign releases, or modify infrastructure, reserving those actions for trusted branches only.

Why It Matters for Security Teams

Untrusted checkout is dangerous because it collapses the boundary between code review and code execution. Once attacker-controlled content runs inside a privileged pipeline, secrets can be exfiltrated, artifacts can be poisoned, and build metadata can be manipulated to mislead downstream consumers. The risk is especially severe in modern software supply chains where automation tokens, package publishing rights, and cloud credentials are often present in the same runner environment.

For security teams, the practical challenge is to treat checkout trust as a governance decision, not just a developer convenience. That means separating low-trust validation from privileged release activity, constraining job permissions, and applying provenance-aware controls that reflect NIST guidance on protecting assets and access paths. It also means recognising that a workflow may be secure in one branch context and unsafe in another, depending on who can influence the code being executed.

Organisations typically encounter the consequences only after a malicious pull request, secret leak, or compromised dependency has already been executed in the runner, at which point untrusted checkout becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does just-in-time access reduce risk more than traditional checkout?
• How should organisations implement PSD2 controls without adding too much checkout friction?
• Should organisations prioritise zero standing privilege over traditional PAM checkout?
• What should teams do when an agentic browser must handle untrusted content?