Why do self-hosted runners and long-lived tokens increase supply chain risk?

Why self-hosted runners change the trust boundary

Self-hosted runners are not just build workers, they are machines you operate, patch, observe, and trust to execute code with access to your delivery environment. That changes the risk profile from “a job ran” to “an endpoint with credentials ran untrusted or semi-trusted code.” If the runner is reachable from the internet, shared across projects, or left with broad permissions, it becomes a persistence point rather than a disposable execution slot.

A hosted runner usually resets the environment between jobs. A self-hosted runner can retain files, tokens, caches, environment variables, and local state unless you deliberately strip them. That means compromise is not limited to the current pipeline run, because a later job may inherit what the previous one left behind.

That same trust boundary is why secure pipeline design treats runner identity, network access, and job isolation as first-class controls. CI/CD Pipeline Identity Security Guide is useful here because it frames runners as part of the identity and authorization surface, not just build infrastructure.

Why long-lived tokens make compromise durable

Long-lived tokens turn a one-time theft into an ongoing access problem. If a token can authenticate to GitHub, a package registry, or a cloud service for weeks or months, then anyone who copies it can reuse that access long after the original event, the original engineer, or the original build has ended. The longer the TTL, the more time an attacker has to wait, test, move laterally, and blend into normal automation.

That matters because supply chain compromise often begins with something small, such as leaked credentials in a log, a cache, a build artifact, or a developer workstation. A long-lived token widens the blast radius by making revocation slower, detection less urgent, and re-use more likely across environments. Short-lived credentials reduce the window in which stolen material remains useful, which is why lifecycle and rotation discipline are central to reducing supply chain exposure. Guide to NHI Rotation Challenges and Ultimate Guide to NHIs, Static vs Dynamic Secrets both reinforce that long-lived credentials are structurally harder to contain once exposed.

For supply chain environments, this is especially dangerous when a token can publish packages, sign artifacts, or reach production cloud APIs. Guide to the Secret Sprawl Challenge is relevant because it shows how exposed credentials in build and developer ecosystems quickly become reusable attack material.

How these two conditions combine into supply chain risk

The risk compounds when a self-hosted runner has a credential that survives beyond the job. An attacker who gains code execution on the runner may steal the token, then reuse it to publish malicious packages, tamper with artifacts, alter releases, or access adjacent cloud services. That is why the issue is not just “build compromise”, it is “credentialed compromise of the delivery path.”

Supply chain attacks often succeed by turning trusted infrastructure into a relay for malicious actions. A runner with persistent credentials can be used to push poisoned updates, modify build outputs, or retrieve downstream secrets from places the pipeline legitimately needs to reach. The same access that makes automation efficient can make abuse look routine if the token is not tightly scoped and quickly expired. For that reason, package publishing and build provenance controls should be treated as part of supply chain defense, not as separate hygiene tasks. SLSA and NIST SSDF (SP 800-218) both support the principle that integrity depends on controlled build trust and controlled release paths.

Risk and Threat Considerations

Self-hosted runners and long-lived tokens create a high-value combination for attackers because they offer both execution and persistence. If the runner is compromised, the attacker may inherit a credential that remains valid after the malware or session that captured it is gone, which lets them return later or operate from another system.

Failure mechanism: the runner executes untrusted code in an environment that still contains reusable tokens, cache contents, or inherited secrets, so the attacker steals credentials and reuses them outside the original job boundary.

Impact: the attacker can publish malicious artifacts, impersonate automation, access adjacent services, and widen the blast radius from one compromised job to the broader delivery chain.

Practitioner Guidance

What to prioritise: treat runner isolation and credential lifetime as one design decision. If a runner can reach production systems or package registries, assume a token leak is a supply chain incident until proven otherwise.

What to verify: confirm that each runner has scoped network reach, no unnecessary persistent state, and credentials that expire fast enough to make exfiltration low value. Also verify that publishing, signing, and deployment permissions are separated instead of bundled into one broad automation token.

Decision rule: if the same secret can both authenticate the runner and change release state, shorten its lifetime, narrow its audience, and move it out of reusable storage before you add more pipeline features.

Practitioner takeaway: the objective is not to make automation secret-free, it is to prevent any stolen automation credential from becoming durable release authority.

Related resources from NHI Mgmt Group

• Why do long-lived registry tokens increase supply chain compromise risk?
• Why do long-lived GitHub tokens and over-permissioned apps increase supply chain risk?
• Why do long-lived automation tokens increase supply chain risk?
• Why do long-lived NHI credentials increase supply-chain risk?