Self-hosted runner security is the protection of CI/CD execution workers that the organization runs in its own infrastructure rather than using fully managed vendor-hosted runners. It matters because self-hosted runners often have more network reach and persistence than managed ephemeral workers.
What is Self-Hosted Runner Security?
These runners can be powerful but risky because they may retain state between jobs, access internal systems, or run untrusted code from pull requests or partner integrations. Hardening focuses on isolation, trust boundaries, cleanup, and permission scope.
What Self-Hosted Runner Security Commonly Supports
Common uses include CI/CD hardening, internal build isolation, secure deployment automation, and runner governance.
Self-Hosted Runner Security vs. Managed Ephemeral Runner Model
Self-hosted runners give more control but often more risk if not isolated carefully. Managed ephemeral runners usually reduce some persistence and infrastructure burden.
Frequently Asked Questions
Why are self-hosted runners risky?
Because they may bridge untrusted code execution with sensitive internal access or long-lived machine state.
Should teams avoid self-hosted runners entirely?
Not necessarily. They can be necessary, but they should be treated as sensitive infrastructure.
Related Cybersecurity Terms
