Runner isolation and protection

Runners (or execution agents) are the environments where CI/CD pipelines are actually processed. If a runner is compromised, the entire build and delivery chain can be manipulated - from the introduction of backdoors to the exfiltration of secrets or the sabotage of artefacts.

Runner security defines the trust boundaries of automated execution.

---

🎯 Objectives

• Ensure that pipelines are executed in secure, controlled and ephemeral environments;
• Prevent malicious code from compromising the runner or escaping the pipeline context;
• Reduce the attack surface associated with shared, persistent or misconfigured runners.

---

🛠️ Practices

1. Execution on ephemeral or re-imageable runners

   • Each job must run in an isolated environment (e.g. VM, container);
   • Runners must be destroyed, restored or validated after each execution.

2. Segregation by risk level and by project

   • L2 and L3 applications must not share runners with external or less critical projects;
   • Production runners must be dedicated and isolated from development environments.

3. Hardening of execution environments

   • Runners must be minimal, up to date and have the smallest possible attack surface;
   • The base system must have strict control over binaries, permissions and active services.

4. Integrity verification of agents and base images

   • Images must be signed and of validated origin;
   • The binaries and scripts used must be verified by hash or digital signature.

5. Prohibition of privileged execution

   • Pipeline jobs must not run as root nor with elevated permissions;
   • Execution of commands such as sudo, setcap, or direct access to docker must be blocked.

---

⚖️ Proportional application by risk level

Level	Mandatory requirements	Enhanced requirements
L1	Up-to-date runners; basic isolation per job	-
L2	Dedicated runners per project; hardened image	Periodic integrity verification
L3	Ephemeral runners, segregated by criticality; signed images	Formal hardening; no root; continuous auditing

---

📌 Practical examples

• GitHub Actions

  • Use of dedicated self-hosted runners per project or critical application;
  • Validation of images with act, cosign or sigstore.

• GitLab Runners

  • autoscaling runners (on Kubernetes, EC2 spot) for per-job isolation;
  • Execution via docker+machine or k8s with automatic destruction.

• Azure DevOps

  • Dedicated pools per project; use of minimal images with pre-applied hardening;
  • Blocking of access to local resources and disabling of elevated privileges.

• Jenkins

  • Agents controlled by labels and node restriction (logical isolation);
  • Pipelines with agent { docker { image: "signed" } } and prior hardening.

---

📉 Mitigated risks

• Persistence of malware between executions (OSC&R: CI0009);
• Exfiltration of secrets via contaminated runners (OSC&R: CI0003, CI0016);
• Privilege escalation via excessive permissions (OSC&R: SC0006);
• Compromise of the build through manipulation of the environment (OSC&R: CI0005).

---