What breaks when CI/CD runners are trusted by default?

Why This Matters for Security Teams

Trusted-by-default runners turn a build system into a high-value execution environment. Once a runner can fetch secrets, reach internal services, or publish artefacts without strong boundaries, any compromise in the pipeline can become a supply chain event. That matters because build trust is often inherited from platform convenience rather than explicit risk analysis. NIST’s control families in the NIST SP 800-53 Rev 5 Security and Privacy Controls are useful here because they separate access control, monitoring, and system integrity into distinct responsibilities instead of treating the runner as a benign utility.

The practical problem is that CI/CD systems are designed to move fast, so security exceptions become defaults: long-lived tokens, broad repository permissions, and network paths that reach places a normal developer workstation never should. If the runner is also reused across jobs, one malicious step may persist long enough to observe another job’s secrets or manipulate cached content. That is why the issue is not just “can code execute,” but “what authority comes along with execution.”

In practice, many security teams discover the weakness only after a poisoned dependency, compromised action, or leaked token has already been used to alter a release pipeline rather than through intentional hardening reviews.

How It Works in Practice

A CI/CD runner becomes risky when it is treated as a trusted intermediary instead of a constrained execution boundary. In a healthy design, each job receives the minimum identity, the minimum network reach, and secrets that expire quickly after use. Current guidance suggests aligning this model with least privilege, short-lived credentials, isolated runners for sensitive builds, and explicit egress controls so the pipeline cannot freely call every internal endpoint.

From an operational perspective, teams should assume that any step in the workflow can be influenced by external code, especially when pulling dependencies, generated scripts, or reusable actions. That means hardening needs to cover both identity and software integrity:

• Use ephemeral runners for untrusted or high-risk jobs so compromise does not persist across workloads.
• Separate build, test, and release privileges so a test job cannot sign or publish artefacts.
• Store secrets outside the runner context where possible, and issue them just in time.
• Restrict outbound access to only the services required for that job.
• Verify artefact provenance and integrity before promotion to later stages.

For broader pipeline governance, OWASP Top 10 CI/CD Security Risks is a strong companion reference because it reflects the real abuse paths seen in modern delivery systems, not just generic server hardening. Where organisations use cloud-hosted runners, the same controls should extend to identity federation, workload identity, and cache isolation. If the runner can impersonate a deployment identity, it should be treated as a privileged system, not a utility process.

These controls tend to break down when runners are shared across repositories and build steps can import arbitrary code, because the trust boundary becomes too wide to enforce meaningful isolation.

Common Variations and Edge Cases

Tighter runner isolation often increases operational overhead, requiring organisations to balance build speed against stronger containment. That tradeoff is real, especially in high-volume engineering environments where shared runners reduce cost and simplify maintenance. Best practice is evolving, but there is no universal standard for how much isolation is enough; the right answer depends on whether the pipeline builds public code, protected internal code, or production release artefacts.

Edge cases matter. Self-hosted runners on flat networks are especially dangerous because compromise can move laterally into internal services. Reusable workflows can also hide privilege inheritance, where a low-trust repository invokes a high-trust automation path. Cache poisoning is another common failure mode because trusted jobs may consume artefacts created by an earlier untrusted run. In organisations using agentic automation, the runner may also provide tool access to an AI agent, which raises the stakes because the agent can execute actions, not merely generate text. In that case, identity, policy, and output validation need to be applied to both the runner and the agent.

For governance and detection, CISA Secure Software Development Framework is useful for mapping pipeline hardening to secure development practices, while MITRE ATT&CK helps teams think about initial access, credential theft, and persistence paths inside delivery environments. The main lesson is simple: a runner should not be trusted because it belongs to the build system; it should be trusted only for the narrow action it is authorised to perform.

Related resources from NHI Mgmt Group

• What breaks when CI/CD runners are reused across jobs?
• Should organisations treat CI/CD runners as privileged identities?
• What breaks when secrets are stored on CI runners and developer machines?
• What breaks when CI/CD OIDC trust still points to a deleted namespace?