CI runner images need privileged-risk ranking, not exposure scoring

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Upwind's blog post: CI runner images can carry deploy authority, signing keys and registry rights, so their risk must be ranked by reach and lineage rather than internet exposure.

Why it matters: IAM, NHI and cloud security teams need to treat build images as privileged identities in the software supply chain because a compromised runner can alter what production trusts.

Context

Build systems create a trust problem as much as a delivery problem. The image that runs a pipeline can inherit cloud roles, push artefacts, sign releases and touch secrets, which means the real security boundary sits inside the CI path rather than only around the published application.

That matters because a short-lived runner can do damage before scheduled monitoring notices anything unusual. Treat container security as part of the software supply chain, not only as a runtime concern, because the runner image often has more effective privilege than the workload it produces.

When a build image is owned by no one, exposure scoring and standard vulnerability workflows both fail in the same way: they track the visible service and miss the privileged ephemeral system making the service possible.

Key questions

Q: How should teams rank CI runner images for risk?

A: Rank CI runner images by who can change them, where they come from, and what credentials they can reach. The highest-risk images are mutable, shared, or broadly privileged, especially if they can access secrets used by deploy roles. Prefer minimal, signed images, separate runners for sensitive pipelines, and short-lived credentials over long-lived tokens.

Q: Why do build images matter in supply-chain attacks?

A: Build images matter because attackers can hide malicious code, tools, or altered dependencies inside the image that executes your pipeline. If trusted releases are built from a compromised image, the build process itself becomes a delivery path for tampered artefacts, credential theft, or poisoned outputs. Image provenance, signing, and controlled base images reduce that exposure.

Q: How does registry scanning help protect CI pipelines?

A: Registry scanning helps by checking stored images for known vulnerabilities, suspicious packages, and policy violations before they are pulled into CI jobs. Scanning builder images is especially useful because those images shape the tools, libraries, and runtime available to the pipeline, which affects both attack surface and the chance of introducing unsafe dependencies.

Q: What should teams do first when a hosted runner is involved?

A: First confirm whether the hosted runner is ephemeral, what network and filesystem access it has, and which secrets or tokens are mounted into it. Then restrict the job to the smallest possible permissions, because a hosted runner is a shared execution surface and any exposed credentials or writable workspace can be abused during the run.

Technical breakdown

Why builder images are privileged even when they are short lived

A CI runner image is not just a disposable execution environment. It frequently pulls source, assumes a cloud role, reads secrets, signs artefacts and pushes images to registries before disappearing. That combination makes it a privileged non-human identity in practice, even when no human logs into it directly. The technical risk comes from the reach of the job, not from the public exposure of the host. When the runner image is reused across pipelines or branches, the same artifact can inherit different authority depending on where it is deployed. See the Cloud PAM and CIEM Guide.

Practical implication: Classify runner images by the roles and secrets they can reach, not by where they sit on the internet.

Registry scanning vs runtime scanning for CI images

Registry scanning works because the image is stationary long enough to inspect. Runtime scanning works because it can observe what the job actually did, but only when the sensor can run where the job runs. Hosted CI breaks that assumption because the runner may be outside your control and gone before any scheduled scan arrives. The control challenge is therefore split between the registry, where images wait, and the runtime, where ephemeral jobs execute. Neither view alone is complete for build-path security. See the Container Image Security Guide.

Practical implication: Scan both the registry and any runnable build agents, and route uncontrolled hosted images through registries you govern.

Cloud trust policies can turn a pipeline into a production path

The most dangerous part of a build path is often not the image itself but the trust policy attached to it. If a single broad rule allows any pipeline or branch to assume a production role, the runner becomes a privileged bridge from code change to deploy authority. That is an identity and access design issue, not just a container issue. The job may be short-lived, but the cloud permissions it can assume determine whether compromise stays local or reaches production systems.

Practical implication: Scope CI trust policies to specific pipelines, branches and image digests so one compromised build cannot assume broad deployment rights.

Threat narrative

Attacker objective: The attacker wants to turn the build system into a trusted distribution channel for malicious or altered releases.

1. Entry occurs through a compromised build dependency, poisoned action, or vulnerable runner image in the CI path.
2. Credential access follows when the job can read secrets, assume cloud roles, or expose signing keys during the build.
3. Escalation happens when the compromised runner uses those permissions to push trusted artefacts or modify what later deploys.
4. Impact is supply-chain compromise, where downstream images or releases inherit attacker-controlled changes and valid trust.

Breaches seen in the wild

• Carbonato botnet 2026: A botnet puts a Hermes AI agent on exposed Docker hosts to steal AI API keys, SSH keys and tokens, powering the operators' own LLM gateway.
• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Build runners are privileged identities, not expendable infrastructure: the security model fails when teams treat CI images as temporary plumbing rather than as actors with deploy authority. A runner that can assume cloud roles, sign artefacts or push to a registry should be governed like any other high-impact identity, even if it exists only for minutes. The practitioner conclusion is to rank the builder by reachable privilege, not by visibility.

Exposure-based prioritisation is backwards for CI supply chains: a public API may deserve attention, but it is not automatically the most dangerous system in the environment. Build images often sit outside the internet-facing asset model while retaining access to deployment roles and signing material, which means traditional scoring misses the system that can change production trust. The practitioner conclusion is to prioritise reach, lineage and privilege over perimeter status.

Hosted runners create a visibility gap that registry controls must cover: when the execution environment is not yours, the only durable control points are the images, the cloud roles and the audit trail you still own. That makes registry governance and trust-policy scoping the practical substitute for sensor placement on third-party infrastructure. The practitioner conclusion is to govern what the runner can touch, not the runner host itself.

Pipeline trust policies are now identity policy decisions: the article makes clear that one broad branch-agnostic rule can give any build path production authority. That is a governance failure in the identity layer, because the policy determines who or what can act on behalf of the pipeline. The practitioner conclusion is to narrow assumption rules until each build identity has only the authority its workflow truly needs.

Build-path exposure debt: organisations accumulate it when builder images, base images and hosted actions stay unowned, untracked and overtrusted. The longer those gaps persist, the harder it becomes to answer whether a compromised builder still reaches production artefacts. The practitioner conclusion is to inventory the full build path before the next incident forces the question.

What this signals

Build-path governance will become a default priority: security teams will increasingly have to treat runner images, hosted actions and build trust policies as first-class assets rather than operational background noise. The programmes that win here will be the ones that connect inventory, lineage and permission scoping before an incident forces a manual hunt.

Build-path exposure debt: the next phase of supply-chain defence is less about scanning what gets deployed and more about proving which build identities can create trusted artefacts in the first place. That means identity governance moves upstream into the CI path, where ephemeral privilege is granted and forgotten in the same workflow.

Hosted CI shifts the monitoring burden to the controls you own: when the execution environment is outside your tenancy, the only reliable signals are the cloud roles, registries and audit logs under your control. The practical response is to design for provenance and least privilege at issuance time, not after the job has already vanished.

For practitioners

• Prioritise runner images by reachable privilege Rank CI images by the deploy roles, registry push rights, signing keys and secrets they can access, then move them ahead of internet-facing but less privileged services.
• Inventory every registry the build path touches Connect application registries, base-image repositories, CI tool images and any mirrors or caches so a single inventory covers every image the runners can pull.
• Scope trust policies to specific pipelines and branches Restrict cloud-role assumption so only named pipelines, branches and digests can take on deployment authority, and remove broad wildcard trust rules.
• Trace each builder to the images it produced Maintain a lineage view that maps every runner or builder image to the artefacts it created and the environments where those artefacts run today.
• Flag stale runner images and baked-in credentials Treat build images older than six months, or images that contain credentials in layers, as findings requiring review and rotation of any exposed secrets.

Key takeaways

• CI runner images can be the most privileged part of the delivery path because they may sign, push and deploy artefacts even when they are not internet-facing.
• Traditional exposure scoring can miss the real blast radius when the build system, not the published service, is the point of compromise.
• Teams need lineage, registry coverage and scoped trust policies to govern build identities before an attacker turns the pipeline into a release channel.

Related NHI Mgmt Group resources: Container Security Guide · Top 10 Container Security Risks · Container Image Security Guide · Cloud PAM and CIEM Guide

Key terms

• CI Runner Image: A CI runner image is the operating system image or container template used to start a continuous integration runner. It defines the tools, libraries, and default configuration available to build jobs, and therefore the execution environment that can also expose credentials, caches, and other build-time secrets.
• Build Path: A build path is the sequence of steps, tools, and inputs used to produce software artefacts from source. It includes compilers, scripts, dependencies, and intermediate outputs, so any weakness in the path can alter the resulting artefact or expose the build process to tampering.
• Hosted Runner: A hosted runner is a temporary execution environment managed by the platform to run CI/CD jobs. It reduces local administration, but security teams still need to control permissions, secrets, and workflow content because the runner can process untrusted code and interact with sensitive build artifacts.
• Build identity: The set of credentials, tokens, keys, and permissions used by CI/CD systems, runners, and developer tooling. Build identity is often overlooked, yet it can expose secrets, alter repositories, and propagate compromise into downstream software if not tightly scoped and monitored.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.