How should security teams harden CI/CD builds against attacks that happen inside the runner at runtime?

Why This Matters for Security Teams

CI/CD runners are not just build utilities; they are high-trust execution environments with access to source code, secrets, caches, signing keys, registries, and cloud endpoints. If an attacker lands inside the runner at runtime, code review and artifact scanning are already too far left to stop abuse. That is why build-time hardening must include process telemetry, outbound network control, and file-system enforcement while the job is live, not only after the artifact is published.

This risk is especially visible in supply chain incidents where the runner itself becomes the compromise point. NHIMG’s The State of Secrets Sprawl 2026 notes that 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations. That aligns with broader guidance from the NIST SP 800-53 Rev 5 Security and Privacy Controls, which treats continuous monitoring, least privilege, and boundary protection as operational controls rather than documentation exercises. In practice, many security teams encounter runner abuse only after secrets have already been exfiltrated or build steps have been altered.

How It Works in Practice

Hardening inside the runner starts by treating each job as an untrusted workload with tightly scoped runtime policy. The goal is to make the runner observable and restrictive enough that malicious shelling, tool chaining, and secret theft become noisy or impossible. That usually means combining ephemeral credentials, process allowlists, restricted egress, immutable workspaces, and runtime detection tied to the expected build graph.

A practical pattern looks like this:

• Issue short-lived credentials only for the job that needs them, then revoke them automatically when the build ends.
• Use workload identity rather than static machine credentials so the runner proves what it is at runtime, not just what it knows.
• Monitor spawned processes, child shells, package installers, archive tools, compilers, and scripting runtimes for deviations from the expected build plan.
• Restrict outbound traffic to known package registries, source mirrors, artifact stores, and update endpoints.
• Mount secrets only when needed, in memory where possible, and never leave them on disk after task completion.

That approach is consistent with the MITRE ATT&CK Enterprise Matrix, which is useful for mapping runtime behaviors such as credential dumping, persistence, and exfiltration. It also aligns with NHIMG’s CI/CD pipeline exploitation case study, which shows why controls around the pipeline perimeter are insufficient when the attacker executes within the job itself. For teams building detections, CISA cyber threat advisories remain a useful source for current tradecraft patterns and defensive priorities.

These controls tend to break down in self-hosted runners with broad host access because local privilege boundaries are often weaker than the build policy assumes.

Common Variations and Edge Cases

Tighter runtime control often increases build complexity, so organisations must balance execution speed and developer convenience against stronger containment. The exact design depends on whether the runner is ephemeral, shared, Kubernetes-based, or a long-lived VM, and current guidance suggests there is no universal standard for policy depth in every environment.

Ephemeral runners are easier to harden because the host can be rebuilt often, but they still need runtime inspection if jobs can fetch and execute remote code. Shared runners require stronger tenant separation, because one compromised job can influence caches, workspaces, or local tooling for the next job. Kubernetes-based runners can benefit from namespace isolation, seccomp, and network policy, but those controls fail if the build pipeline can still mount privileged pods or reach the node metadata service. Long-lived runners are the hardest case because persistence can survive beyond a single job unless the environment is aggressively reimaged.

NHIMG’s Guide to the Secret Sprawl Challenge is relevant here because runtime hardening only works when secret exposure is paired with automatic revocation; detection without cleanup leaves stolen values usable. For broader attacker behavior, the 52 NHI Breaches Analysis reinforces a recurring pattern: once machine identity is abused during execution, lateral movement and repeat access often follow unless the environment is rebuilt and credentials are rotated immediately.

Related resources from NHI Mgmt Group

• How should security teams secure CI/CD pipelines against man-in-the-middle attacks when dependencies and scripts are fetched dynamically?
• How should teams secure CI/CD pipelines against identity-based attacks?
• How should security teams harden MFA against code-guessing attacks?
• How should security teams handle browser-based attacks that happen inside the session?