Because they let an attacker move from initial compromise to trusted release authority. If a runner can access signing material, a malicious build can inherit a valid signature and appear legitimate downstream. That changes one compromised system into a distribution channel for tampered software.
How over-permissioned build runners turn build access into release authority
A build runner is supposed to execute a narrow, repeatable job: fetch source, build artifacts, and hand them back. The risk changes when that runner also holds privileges that let it read secrets, reach production systems, or sign releases. At that point, a compromise stops being a one-off CI incident and becomes a path into trusted distribution.
That is why the same runner permissions that look convenient in a fast-moving pipeline can quietly erase the boundary between “build system” and “software publisher.”
When build infrastructure crosses that boundary, the control question is no longer just whether the runner can compile code, but whether it can also preserve build provenance and artifact integrity. If the runner can sign, publish, or reach secrets used for signing, it can turn a compromised job into a trusted release path.
Why signing material and publish tokens are the critical blast-radius multiplier
The highest-risk permission is direct or indirect access to signing material, package publish tokens, or credentials that can mint a release artifact downstream. If an attacker injects code into a job that already has that trust, the malicious output can inherit the organisation’s legitimacy and pass routine downstream checks.
That is the distinction practitioners should keep in view: an over-permissioned runner is not only a place where code runs, it is a place where trust can be manufactured. In supply chain terms, the attacker is trying to move from code execution to distribution authority, which is why tooling around the software build path needs explicit provenance, isolation, and release controls.
Real-world supply chain compromises show the same pattern in different forms. In one case, poisoned build infrastructure exposed signing material, and in another, stolen publishing access let attackers ship malicious releases to package registries. The common failure is not the malware family, it is the excess privilege attached to the build environment.
That is also why secure software supply chain guidance such as NIST SSDF (SP 800-218) matters here: it directs teams to treat build and release activities as governed security processes, not just developer convenience.
What changes when the runner can reach more than the build step
Over-permissioning usually expands in small increments, such as adding broader repository access, long-lived tokens, secret vault read access, artifact repository write access, or cloud credentials for deployment. Each addition makes the runner more useful, but also more attractive as a pivot point after initial compromise.
The practical danger is lateral reuse. A token intended for CI automation can become the easiest way to reach signing keys, package registries, infrastructure APIs, or cloud resources. Once an attacker controls the runner, they often do not need to break the next system directly, because the runner already has the trust path they want.
That pattern is especially visible in ecosystems where OpenSSF guidance emphasises securing the open source software supply chain, and where registry access, build scripts, and CI secrets all sit close together. The more the runner can do, the more carefully its permissions need to be separated by job, environment, and release stage.
In practice, the question is not whether the runner can be trusted when everything is healthy. The question is how much authority it still has after a token leak, dependency compromise, or malicious pull request has already happened.
Risk and Threat Considerations
Over-permissioned build runners create a high-value compromise path because they sit close to source code, secrets, and release workflows at the same time. If the runner is abused, the attacker can often tamper with artifacts, exfiltrate credentials, or publish software that looks legitimate to consumers and downstream automation.
Failure mechanism: Excess permissions let a compromised runner read signing material, reuse publish tokens, or access deployment credentials, which collapses the boundary between build execution and trusted release authority.
Impact: A single runner compromise can scale into registry poisoning, signed malicious releases, environment-wide secret exposure, and downstream trust loss across customers and internal systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Build runner privilege directly affects provenance and artifact integrity. |
| Recommendation — Separate build, sign, and publish steps so compromised runners cannot mint trusted releases. | ||
| NIST SP 800-53 Rev 5 | SA-10 — Developer Configuration Management | Build runners are part of controlled development and release processes. |
| IA-5 — Authenticator Management | Runner tokens and signing secrets require lifecycle control and rotation. | |
| Recommendation — Restrict CI runner permissions to the minimum needed for approved build activities. Inventory, rotate, and revoke CI credentials before they become reusable release paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | Over-permissioned runners are an account and token governance problem in the build path. |
| Recommendation — Eliminate standing access that lets build systems act beyond their intended job scope. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Runner privilege should be governed as a formal access control decision. |
| Recommendation — Define and enforce least-privilege access for build and release identities. | ||
Practitioner Guidance
What to verify: Confirm that build runners cannot read signing keys, long-lived publish tokens, or production secrets unless the specific job absolutely requires it. If they can, treat that as a release design issue, not a minor CI configuration detail.
What good looks like: Separate build, sign, and publish functions so the runner that compiles code is not automatically the runner that vouches for it. Use the smallest permission set that still allows the job to complete, and make the trust boundary visible in pipeline design.
Decision rule: If a runner compromise would let an attacker produce an artifact that downstream systems accept as legitimate, reduce privilege before you tune detection. At that point, blast-radius control matters more than pipeline convenience.
Practitioner takeaway: Treat runner privilege as release authority, because once a build system can sign or publish, compromise of that system becomes a supply chain compromise, not just a CI incident.
Related resources from NHI Mgmt Group
- Why do build systems increase supply chain risk in software teams?
- Why do build servers and CI runners increase supply chain risk?
- Why do build pipelines, registries, and base images increase software supply chain risk in cloud native environments?
- Why do long-lived GitHub tokens and over-permissioned apps increase supply chain risk?