How do you detect changes to GitHub self-hosted runners?

Detect runner changes by alerting on runner registration, removal, label changes, and configuration changes in repository or organisation audit activity. Review which runner groups can access which repositories, and watch for new or replaced runners that could intercept workflow secrets or alter build output. Treat unexpected runner changes as a potential compromise.

What actually changes when a GitHub self-hosted runner changes

A self-hosted runner is more than an execution host, it is part of the trust boundary for CI/CD. If a runner is added, removed, relabelled, or reconfigured without explanation, the risk is not just operational drift. It can change which workloads run where, which repositories can reach that runner, and whether workflow secrets or build outputs could be exposed or altered.

That is why change detection should focus on the audit trail, not only on the host itself. In GitHub, the useful signals are runner registration and removal events, label updates, configuration changes, and changes to runner group access. Those events tell you whether the fleet is behaving as expected or whether a new runner may have been introduced to intercept jobs.

For coverage, the most useful related control point is your broader CI/CD identity and trust model. NHI’s CI/CD Pipeline Identity Security Guide is useful here because runner trust, token scope, and build integrity are linked, not separate problems. A runner change can be the first visible sign that the pipeline boundary has shifted.

Which audit signals and permission changes matter most

The highest-value detections are the ones that reveal a change in execution authority. A new self-hosted runner, a renamed or relabelled runner, or a runner that suddenly joins a different group can silently redirect jobs. If the runner group can now access more repositories than before, you should treat that as an access expansion event, not a housekeeping detail.

Configuration changes matter for the same reason. Reimage, replacement, label reassignment, and runner-setting updates can all be benign, but they are also the normal mechanics of compromise and persistence. An attacker who can place a malicious runner in the right group does not need to break workflow code if they can wait for the pipeline to hand them a job.

Use the audit activity from the repository and organisation together, because one view is often incomplete. Repository-level activity shows the workflow surface, while organisation-level activity shows fleet-level changes and access governance. Combining both helps you distinguish a planned fleet update from a runner introduced outside the normal change process.

For a broader security baseline, GitHub runner monitoring maps well to common audit, configuration and access-control discipline described in NIST’s Cybersecurity Framework 2.0. The practical point is to log and review runner changes as part of ongoing detection, not as an after-the-fact investigation only.

How to confirm whether a runner change is benign or suspicious

Start by comparing the event against your approved runner inventory. A legitimate change should have a clear owner, a deployment reason, and an expected maintenance window. If the runner is new, ask where it came from, who registered it, and whether it matches the standard build image or bootstrap process.

Then verify whether the runner is associated with any unexpected repository reach. The key question is whether the runner can now execute jobs for repositories it did not previously serve. If yes, check whether that expansion was deliberate and whether the runner has access to any sensitive workflows, secrets, or deployment paths.

Also look for paired indicators of compromise around the same time. A runner replacement followed by unusual workflow failures, altered artefact output, or secret access events is more concerning than an isolated configuration change. The control is not simply “did a change happen”, but “did the change alter trust, reach, or job execution in a way that should not have occurred”.

Risk and Threat Considerations

Self-hosted runner compromise is dangerous because the runner sits inside the execution path for trusted automation. A malicious or replaced runner can observe workflow inputs, influence build results, or interact with credentials that are only meant to exist during job execution. That makes runner changes a practical detection point for both persistence and pipeline abuse.

Failure mechanism: An attacker registers or replaces a runner, changes its labels or group membership, then waits for scheduled or triggered jobs to land on the compromised host so it can capture secrets or tamper with output.

Impact: The result can be secret exposure, poisoned builds, modified releases, or unauthorized access to downstream systems that trust the CI/CD pipeline.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	DE.CM-01 — Networks and network services are monitored to find potentially adverse events	Runner changes are detected through ongoing monitoring of audit events and fleet activity.
	PR.AA-05 — Identities are proofed, bound to credentials, and authenticated before accessing resources	Runner trust depends on controlling which runner identities can access which repositories.
	PR.DS-10 — Confidential data is protected during transmission	Compromised runners can expose workflow secrets and sensitive job data in transit during execution.
Recommendation — Monitor runner registration, removal and configuration events for unexpected changes. Restrict runner access to approved repositories and groups only. Treat new or replaced runners as potential secret-exposure points until verified.
MITRE ATT&CK	T1098 — Account Manipulation	Runner registration and group changes can be used to persist or expand access in CI/CD environments.
	T1552 — Unsecured Credentials	Compromised runners may expose workflow secrets or tokens during job execution.
Recommendation — Hunt for unauthorized registration or permission changes that alter runner access. Investigate runner changes for opportunities to steal secrets or tokens from workflows.

Practitioner Guidance

What to verify: Tie each runner event back to a known change request, approved image, or automation path. If you cannot explain why the runner appeared, changed labels, or moved groups, treat it as a security event rather than an admin task.

What good looks like: Your inventory, audit log, and runner group mappings should agree. Good hygiene means you can answer which repositories each runner can reach, who last changed that relationship, and whether the runner matches the sanctioned build baseline.

Common mistake: Teams often monitor workflow failures but not the runner fleet itself. That misses the more important signal, a runner can be swapped or repurposed before any obvious build breakage occurs.

Practitioner takeaway: Detect runner compromise by watching for trust-boundary changes, not just host changes, because the security question is whether execution authority shifted in ways your pipeline did not intend.