Why do compromised build and runner environments increase the blast radius of supply chain attacks?

Why This Matters for Security Teams

Build and runner environments sit at the point where source code becomes a signed, published, or deployed artifact, so compromise there is not a simple endpoint event. It turns one malicious package, workflow step, or poisoned dependency into access to secrets, registry tokens, and cloud permissions that may be trusted by many downstream systems. NHIMG’s research on Reviewdog GitHub Action supply chain attack shows how quickly automation can become a secret-exposure amplifier when CI runners are overprivileged.

This is why supply chain incidents often expand far beyond the original package or repository. A compromised runner can read environment variables, access cached credentials, tamper with build outputs, and republish artifacts that appear legitimate to downstream consumers. That pattern aligns with the broader risk picture described in the OWASP Non-Human Identity Top 10, where machine-to-machine trust is frequently stronger than the controls around it.

In practice, many security teams encounter lateral movement through build systems only after an attacker has already harvested secrets and used automation to spread the compromise.

How It Works in Practice

The blast radius grows because build and runner environments usually combine three risky properties: broad access, ephemeral execution, and weak inspection. A runner may need to pull private dependencies, authenticate to package registries, push images, access object storage, or trigger deployment workflows. If that runner is compromised, the attacker inherits the same machine identity and any secrets exposed to that job.

Good practice is to treat runners as high-risk workloads, not trusted servers. Current guidance suggests using short-lived credentials, workload identity, and strict job-scoped authorization rather than static secrets baked into images or long-lived CI variables. In agentic or highly automated pipelines, runtime policy evaluation matters because the request context changes from job to job. That is why modern identity guidance increasingly overlaps with NHI controls in the Ultimate Guide to NHIs — Why NHI Security Matters Now.

• Issue secrets per task, not per runner, and revoke them on completion.
• Prefer workload identity and OIDC-based federation over stored cloud keys.
• Lock runners to minimal network paths, minimal filesystem access, and minimal artifact permissions.
• Separate build, test, and release stages so a single compromised job cannot publish production artifacts.
• Inspect provenance, signing, and dependency integrity before release, not after deployment.

For identity controls, the NIST SP 800-53 Rev 5 Security and Privacy Controls supports least privilege, session control, and auditability, while CISA cyber threat advisories repeatedly emphasize hardening automation pathways that attackers can reuse at scale.

These controls tend to break down when runners are shared across repositories and projects because one compromised job can inherit trust boundaries that were never designed for tenant isolation.

Common Variations and Edge Cases

Tighter build isolation often increases engineering overhead, requiring organisations to balance faster pipelines against stronger secret containment. That tradeoff becomes more visible in monorepos, multi-tenant CI, and self-hosted runner fleets where teams want speed, caching, and reusable infrastructure.

Not every environment has the same exposure. Hosted runners can reduce persistence risk, but they do not remove secret sprawl if the workflow still injects long-lived credentials. Self-hosted runners can improve network locality and build performance, but they often increase blast radius if patching, logging, or teardown discipline is weak. There is no universal standard for this yet, but the current direction of travel is toward ephemeral, workload-bound access with runtime policy checks rather than static trust in the build host.

NHIMG’s analysis in The State of Secrets in AppSec shows why this matters operationally: secret leakage is often not detected quickly enough, and fragmented secret management makes containment harder once a runner is exposed. When supply chain compromise is suspected, teams should assume that every credential reachable from that pipeline may already be in an attacker’s hands and rotate accordingly.

That is especially true when runners can access multiple registries, signing keys, and deployment targets from the same execution context, because the compromise then becomes a cross-environment trust failure rather than a single CI issue.

Related resources from NHI Mgmt Group

• Why do non-human identities increase the blast radius of supply chain attacks?
• Why do NHI credentials increase blast radius in supply-chain attacks?
• Why do cloud and AI-tool credentials increase the blast radius of supply-chain attacks?
• Why do SaaS supply-chain attacks create a larger blast radius than direct account compromise?