Why Self-Hosted CI Runners Are a Hidden Security Risk in Build Pipelines

Self-hosted CI runners execute code submitted by anyone who can open a pull request, making them high-value targets that are rarely covered by a formal threat model. Unlike managed runners, self-hosted ones often persist between jobs, retain deployment credentials, and have access to internal network resources. A documented attack chain shows how a malicious pull request can plant modifications on a persistent runner, which are then inherited by a later privileged job with access to production credentials. Key vulnerabilities include shared caches across job boundaries, guessable runner labels, and the runner's network position being exposed even when secrets are withheld from forks. Security experts recommend making runners ephemeral, separating untrusted and release build environments, requiring human approval for first-time contributors, and issuing short-lived per-job credentials to limit exposure.