Runner security hardening

Runner security hardening

Assistance managed runners execute CI/CD jobs inside an agreed customer or Assistance-managed boundary. This page explains the baseline hardening controls, evidence, and operating practices that keep those runners suitable for sensitive builds, private-network access, and EU-focused governance.

This is practical security guidance, not legal advice. Assistance can design controls, operate agreed safeguards, collect evidence, and support audits or incidents. The customer remains responsible for legal determinations, risk acceptance, certification claims, and approvals from security, procurement, data-protection, and business owners.

For platform-specific routing and examples, see GitHub Actions, GitLab runners, Gitea Actions, and Forgejo Actions. For day-2 signals, see Runner monitoring and support.

Security and compliance decisions to make first#

Before production use, agree these choices in writing:

Assistance does not automatically certify a runner fleet as GDPR compliant, ISO certified, SOC 2 compliant, or suitable for a regulated workload. Those claims require the customer's own assessment and any applicable contracted commitments.

Shared responsibility model#

Baseline hardening controls#

Use this checklist as the default target for managed runner production readiness.

Identity, MFA, and access control#

• Use customer-controlled identity providers and accounts where possible, especially for regulated or EU-sensitive workloads.
• Require MFA/SSO for cloud consoles, CI administration, repository administration, and support portals.
• Give Assistance named, least-privilege access rather than shared administrator accounts.
• Separate everyday access from emergency or break-glass access.
• Review runner, cloud, repository, and secret-administrator access on the agreed cadence.
• Remove access promptly when people leave the engagement or no longer need operational access.

Least privilege for jobs#

• Route production deployments to restricted runner labels or tags such as prod-deploy; do not let ordinary build jobs use privileged capacity.
• Keep CI token permissions explicit and minimal. For GitHub, define permissions:. For GitLab, restrict variables, protected branches, protected environments, and protected runners.
• Prefer short-lived identity federation such as OIDC over long-lived cloud keys when the platform and provider support it.
• Do not use runner labels or tags as the only approval control. Combine them with branch protection, environment approval, merge review, and code-owner rules.

Secrets handling#

• Store secrets in the narrowest supported CI or secret-manager scope.
• Keep production secrets away from untrusted pull requests, forks, unprotected branches, and shared low-trust runners.
• Avoid printing environment dumps, shell traces, tokens, private URLs, or credentials in logs.
• Mask secrets where the platform supports it, but do not rely on masking as the only control.
• Rotate secrets after suspected exposure, runner compromise, broad access changes, or personnel changes.
• Record who owns each production credential and who can approve rotation.

Runner isolation#

• Prefer ephemeral runners for jobs that handle secrets, private-network access, production deployments, customer data, or untrusted code.
• Use separate pools for production, non-production, high-risk, GPU, privileged container, and bare-metal/specialized workloads.
• For persistent runners, define workspace cleanup, cache cleanup, user separation, drift checks, and maximum local retention.
• Avoid running unreviewed fork code on runners that can reach internal systems or production secrets.
• For container-based jobs, pin trusted images where practical and define whether privileged mode, Docker-in-Docker, host networking, or mounted sockets are allowed.

Network and egress controls#

• Document which destinations runners may reach: package registries, artifact stores, internal APIs, databases, Kubernetes APIs, deployment targets, and observability endpoints.
• Use allowlists, security groups, private links, VPNs, firewall rules, or egress gateways where the environment supports them.
• Keep production network access on restricted runner profiles.
• Log egress decisions and private-service access where feasible.
• Define the revocation path for an incident: disable labels/tags, revoke runner registration, remove security-group rules, rotate credentials, and block egress.

Patching and vulnerability response#

• Maintain a supported operating-system and runner-agent version baseline.
• Patch runner hosts, base images, container runtimes, language toolchains, and CI agents on an agreed cadence.
• Define emergency patch criteria for actively exploited vulnerabilities, leaked runner tokens, compromised images, and cloud-provider advisories.
• Track vulnerability findings to owner, severity, target date, mitigation, and closure evidence.
• Rebuild or replace runners instead of manually repairing drift when ephemeral or image-based operation is available.

Logs, metrics, and retention#

• Capture runner availability, queue time, job failures, host resource pressure, agent registration state, cleanup failures, update status, and security-relevant events.
• Keep logs long enough for troubleshooting, audit, and incident response, but not longer than the agreed retention period.
• Treat CI logs and artifacts as potentially sensitive because they can contain file names, internal hostnames, branch names, user identifiers, or accidental secret output.
• Record retention choices for job logs, artifacts, caches, runner host logs, monitoring metrics, and support tickets.

Backups and recovery#

Most runner fleets should be rebuildable from code and documented configuration. Back up the things that are not easily recreated:

• runner inventory and label/tag matrix;
• infrastructure configuration and image definitions;
• monitoring dashboards and alert rules;
• audit evidence, change records, and runbooks;
• bare-metal host inventory, firmware settings, and recovery procedures where applicable.

Do not rely on local runner workspaces as backup storage. CI artifacts that must be retained should be uploaded to approved artifact or release storage with an explicit retention policy.

Audit evidence Assistance can provide#

Depending on the engagement, Assistance can prepare:

• runner inventory with platform, environment, region, owner, labels/tags, executor type, and isolation model;
• access review exports or screenshots for runner administrators, cloud roles, repository roles, and break-glass users;
• patch and image update records;
• vulnerability findings and remediation notes;
• monitoring dashboards, alert history, and incident timelines;
• change requests, rollback notes, and maintenance-window records;
• secrets boundary notes and rotation evidence;
• backup or rebuild evidence for configuration and runbooks.

Evidence supports customer review; it is not a replacement for legal advice, customer certification programs, or regulator-facing submissions unless explicitly contracted.

Incident response expectations#

If a runner security event is suspected:

1. Stabilize — stop routing new jobs to the affected runner pool, preserve relevant logs, and avoid destructive cleanup until evidence is captured.
2. Contain — revoke runner registration tokens, remove labels/tags or runner group access, block private-network egress, and rotate exposed credentials.
3. Assess — identify affected repositories, branches, jobs, secrets, artifacts, users, and network destinations.
4. Recover — rebuild runners from trusted images, restore approved configuration, validate monitoring, and rerun only trusted jobs.
5. Document — produce timeline, impact notes, evidence retained, actions taken, remaining risk, and follow-up tasks.

The customer decides regulatory notifications, customer communications, and legal positions. Assistance can provide operational facts and support the customer's incident owner.

Related docs and services#

• Managed runners overview
• Managed runner onboarding
• Runner monitoring and support
• Troubleshooting
• Common runner errors
• Bare metal runners
• Incident response runbook
• Support and escalation