RunSecure
Disposable, hardened containers for self-hosted GitHub Actions runners.
Overview
Self-hosted GitHub Actions runners give you control over hardware, cost, and access to private networks. They also inherit a security model that hosted runners avoid by accident. A self-hosted runner on bare metal is a shared, persistent environment, and a malicious dependency or compromised Action can read SSH keys, exfiltrate cloud credentials, plant background processes, and reach internal services that were never meant to be exposed to CI.
RunSecure is the layer between needing a self-hosted runner and trusting the runner. Every job runs in a fresh, hardened container that is built from a minimal base, dropped to a non-root user, stripped of capabilities and setuid bits, locked to a custom seccomp profile, and routed through an egress allowlist that you explicitly approve. When the job ends, the container ends. Nothing persists, nothing carries forward. For teams that want it always on, a Compose-based orchestrator watches GitHub for queued jobs and spins up these hardened runners on demand.
The egress allowlist is the load-bearing piece. The reason the tj-actions/changed-files compromise of March 2025 had the impact it did is that the attacker could reach arbitrary domains from inside the runner. RunSecure assumes that compromise will happen and ensures that, when it does, the blast radius stops at the network boundary you control. Even a malicious package executing inside the container cannot talk to anything you have not already approved.
It is also deliberately honest about what it does not do. It will not stop exfiltration over a domain you have allowed, vet third-party Actions for you, or keep a workflow from echoing its own secrets into a log. The promise is narrower and more defensible: make the blast radius of a compromised job something you defined in advance. The project is open source under Apache 2.0, because a security floor like this should not be a competitive advantage.
Highlights
- Ephemeral by construction. Each job runs in a fresh container started with --rm and destroyed the moment the job ends. One runner is one container is one job. No state survives.
- Locked down by default. UID 1001 with the root account locked and the shell set to nologin, cap_drop ALL (only NET_BIND_SERVICE on the proxy), no-new-privileges, setuid bits stripped, and a custom seccomp profile blocking ptrace, mount, bpf, keyctl, and swapon.
- A dead end for an attacker. /etc is read-only, the package manager and network recon tools (ping, nc, ssh, wget) are removed at build time, and PID-1 reaping keeps zombie processes from accumulating.
- Egress allowlist as the load-bearing control. Traffic flows through Squid for HTTP/HTTPS, HAProxy for raw TCP, and dnsmasq for DNS. Anything off your allowlist is blocked, and the cloud-metadata endpoints (169.254.169.254, metadata.google.internal, fd00:ec2::254) are refused outright.
- A long-running orchestrator option. A Compose backend polls GitHub for queued jobs and spawns hardened ephemeral runners on demand, coexisting with the single-shot run.sh path rather than replacing it.
- A canary-first release pipeline. Every image is Grype-scanned and only promoted to a stable tag after an acceptance suite passes against the same digest, so the stable tag is byte-identical to the canary it was promoted from.
- Honest about its boundaries. It does not block exfiltration over domains you have allowed, replace the need to vet third-party Actions, or solve secrets management. It makes a compromise far less catastrophic, not impossible.