Runner

The execution environment that performs a GitHub Actions job. Runners can be GitHub-hosted or self-hosted, and both represent access surfaces. If untrusted code reaches a privileged runner, the runner effectively becomes part of the organisation’s identity and control plane.

Expanded Definition

A runner is the execution environment that receives and performs a CI/CD job, such as a GitHub Actions workflow step. In NHI security, the runner matters because it is not just a build machine; it is a control point that may handle secrets, tokens, source code, deployment credentials, and network paths into production systems. GitHub-hosted runners are ephemeral and vendor-managed, while self-hosted runners are organisation-managed and therefore inherit local trust, patching, network, and isolation responsibilities.

Definitions vary across vendors and platforms, but the security pattern is consistent: any runner with access to privileged workflows becomes part of the identity and access boundary. That makes runner hardening, workload scoping, and secret handling central to governing machine-to-machine execution. NIST’s NIST Cybersecurity Framework 2.0 is useful here because runner risk sits at the intersection of protect, detect, and recover controls, especially where automation can modify infrastructure or release artefacts.

The most common misapplication is treating a runner as a disposable build utility, which occurs when privileged jobs, long-lived tokens, or broad network access are placed on a machine without equivalent identity controls.

Examples and Use Cases

Implementing runners rigorously often introduces operational friction, requiring organisations to weigh deployment speed against isolation, patching, and access control overhead.

• A GitHub-hosted runner compiles code and deploys to a staging environment using short-lived credentials, limiting blast radius if a workflow is compromised.
• A self-hosted runner is placed in a segmented subnet and given only the network reach needed for one pipeline, reducing exposure if a malicious pull request is executed.
• An organisation scans runner logs and ephemeral workspace contents for secrets because 96% of organisations store secrets outside of secrets managers in vulnerable locations, including CI/CD tools, according to Ultimate Guide to NHIs.
• A release pipeline uses a dedicated runner pool for production deployments so that untrusted test jobs never share the same execution surface as privileged promotion jobs.
• A platform team aligns runner trust assumptions with guidance from the NIST Cybersecurity Framework 2.0 and applies separate controls for software supply chain integrity.

In practice, runner design also affects how much trust is placed in the pipeline itself. When a runner is ephemeral, it can reduce persistence risk, but it still requires careful secret injection, job scoping, and artifact handling to avoid leakage across steps.

Why It Matters in NHI Security

Runners are security-relevant because they often sit at the point where code becomes action. If a workflow is compromised, the runner can be used to read secrets, impersonate deployment identities, alter build outputs, or pivot into connected systems. That is why runner governance should be treated as part of NHI control-plane design, not merely as DevOps infrastructure management. NHI Management Group’s Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, a pattern that becomes especially dangerous when the runner executing a job can access broad credentials or trusted network zones.

The right questions are identity questions: what can this runner access, how long does that access persist, and what happens if untrusted code reaches it? Industry practice is still evolving on how to classify runners, but the security objective is clear. They should be segmented, minimally privileged, observable, and tightly coupled to the jobs they serve. Organisations typically encounter runner risk only after a workflow compromise or secret exposure, at which point runner governance becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• CI runner
• CI Runner Identity
• Build Runner
• Runner.Worker process