GitHub custom runner images shift CI/CD runtime security left

At a glance

What this is: GitHub’s custom runner images move runtime protection from individual workflows into the runner image itself, creating organisation-wide CI/CD security coverage without per-file edits.

Why it matters: That matters because CI/CD runners often sit where secrets, builds, and source code converge, and identity and access controls around those runners now become a platform governance problem rather than a workflow hygiene problem.

👉 Read StepSecurity's post on baking Harden-Runner into GitHub custom runner images

Context

GitHub Actions security often fails at the point where protection depends on every workflow being updated correctly. When runtime controls live in individual YAML files, the control surface expands with repository count, developer turnover, and pipeline sprawl, which creates inconsistent enforcement across the CI/CD estate. This is a CI/CD governance problem, but it also has an identity angle because runners execute with access to secrets, tokens, and build-scoped privileges.

The move to custom runner images changes where control is enforced. Instead of asking every workflow author to remember the same security step, organisations can standardise runtime protection at the image and runner lifecycle level. That aligns better with the way machine identities and workload credentials are already governed in modern environments, where persistence and consistency matter more than user-by-user opt-in.

Key questions

Q: What breaks when CI/CD security depends on workflow files instead of the runner image?

A: Coverage becomes inconsistent as repositories grow, developers forget security steps, and workflow versions drift. The result is not just operational noise, but uneven runtime protection across builds that should be governed the same way. A control that depends on human memory will always leave gaps in a large pipeline estate.

Q: Why do CI/CD runners need identity governance, not just endpoint-style monitoring?

A: Runners execute with access to secrets, tokens, and deployment pathways, so they function like workload identities with elevated privileges. Monitoring can detect misuse, but only identity governance controls the scope, lifetime, and offboarding of the credentials those runners depend on.

Q: How do security teams know whether runner protection is actually working?

A: Check whether every active build is inheriting the same runtime controls, whether the approved runner image is current, and whether any workflow still depends on a manual security step. If protection varies by repository or author behaviour, the control is not fully working.

Q: Who is accountable when an AI agent in CI/CD exposes secrets or pushes unauthorized code?

A: Accountability sits with the organisation operating the pipeline, because the agent is acting inside delegated authority. The practical question is which team owns trigger design, secret scoping, runtime detection, and incident response. Governance frameworks for access control and zero trust both expect a clear control owner, and agentic workflows do not remove that responsibility.

Technical breakdown

Why workflow-level security breaks down at scale

Traditional GitHub Actions protection depends on each workflow explicitly including a security step. That creates a brittle control model because protection is tied to repository authorship, not to the execution environment. As workflow counts grow, missing steps, version drift, and uneven onboarding become governance failures rather than isolated mistakes. The result is a security control that exists in policy but not always in runtime. In CI/CD, that gap is especially dangerous because the runner can access secrets, artifact stores, and deployment credentials during execution.

Practical implication: treat workflow-file coverage as an audit signal, not a control guarantee, and measure protection at the runner layer instead.

How baked-in runner protection changes the trust boundary

When Harden-Runner is embedded in a custom runner image, the security agent becomes part of the execution substrate. That shifts the trust boundary from the workflow definition to the VM image and its lifecycle management. Every job using that image inherits the same runtime monitoring and policy enforcement without extra workflow edits. Operationally, this resembles infrastructure-level guardrails in cloud environments, where control effectiveness depends on the platform, not on each application team remembering to configure it correctly.

Practical implication: govern runner images as security assets, with change control, versioning, and approval processes equivalent to other privileged infrastructure components.

Why this matters for secrets, tokens, and CI/CD identity

CI/CD runners are not just compute instances. They are high-value execution identities that often handle cloud credentials, deployment tokens, and source-code access during build and release tasks. If those runners are inconsistently protected, an attacker who reaches the pipeline can often move from build context to secret exposure or downstream environment access. StepSecurity’s model reduces one class of inconsistency, but it does not replace secrets hygiene, short-lived credentials, or least-privilege scoping for the runner’s own identity and permissions.

Practical implication: pair runner-level runtime protection with tight credential scope, rotation, and offboarding for any secret or token used by CI/CD jobs.

Threat narrative

Attacker objective: The attacker wants to turn CI/CD execution into a trusted path for secret theft, build manipulation, or downstream environment access.

1. Entry occurs through a compromised or weakly protected CI/CD workflow or runner execution context where the attacker can observe build activity and interact with tooling.
2. Escalation follows if the runner or workflow has access to secrets, tokens, or deployment credentials that are broader than the job actually needs.
3. Impact occurs when the attacker uses those credentials to steal source code, tamper with builds, or pivot into connected cloud and production environments.

NHI Mgmt Group analysis

Workflow-file security is too fragile to be the primary control for CI/CD runtime protection. When security depends on every developer remembering to add the same step, the control becomes probabilistic instead of deterministic. That is a governance failure, not a tooling inconvenience. In practice, organisations need enforcement anchored in the execution environment, not scattered across repositories and pull requests. For teams aligning to NIST CSF and NIST SP 800-53 Rev 5 Security and Privacy Controls, this is a reminder that policy coverage must translate into runtime enforcement.

Custom runner images create a more coherent control plane for CI/CD security, but they also raise the bar for image governance. Baking security into the runner image improves consistency, yet it also means the image itself becomes a privileged security artifact. Versioning, provenance, and rollback discipline now matter as much as the agent being installed. The named concept here is runner image governance debt: the operational risk that builds up when runner images change faster than security teams can validate what is inside them. Practitioners should treat image lifecycle controls as part of their identity and access governance for machine execution.

CI/CD runners behave like high-risk workload identities, not generic compute nodes. They routinely access secrets, tokens, and deployment pathways that can affect production systems. That means identity controls around those runners need to be explicit about privilege scope, token lifetime, and separation of duties. This is where NHI governance intersects with DevOps security: the runner is an identity surface, and the credentials it touches need the same lifecycle discipline as any other privileged account. Teams that ignore this boundary end up with hidden standing privilege in the pipeline.

Platform-level protection is the right direction, but it does not eliminate the need for secrets governance. Runtime monitoring can detect abuse, but it cannot compensate for over-permissioned tokens or long-lived credentials exposed to build jobs. The deeper issue is that many CI/CD controls still assume the pipeline is trustworthy by default. That assumption is increasingly false. Practitioners should use this shift to tighten secret scope, shorten credential lifetime, and reduce the blast radius of every runner identity.

This development signals a broader move from workflow security to infrastructure security in software delivery. The market is converging on controls that attach to the execution layer because that is where consistency and scale become possible. For identity and platform teams, the implication is straightforward: governance models that rely on voluntary developer action will keep producing uneven protection. The control model needs to move with the runtime, or the runtime will keep outrunning the policy.

What this signals

Runner security is becoming a control-plane problem, not a repository hygiene problem. The organisations that will manage CI/CD risk best are the ones that stop relying on workflow authors to enforce security manually. That shift also strengthens the link between pipeline governance and identity governance, because the runner’s credentials are now part of the access model, not just the build toolchain. For policy alignment, map this to the NIST Cybersecurity Framework 2.0 and enforce it through image lifecycle control.

Runner image governance debt: the longer teams maintain multiple ad hoc workflow protections, the harder it becomes to know which jobs are actually protected. That debt grows quietly because the workflows still execute successfully, even when the security step is missing or stale. Over time, this creates a false sense of coverage that only appears when a pipeline is compromised.

Secrets in CI/CD need lifecycle controls, not just detection. The fact that leaked credentials can remain valid long after exposure means pipeline monitoring is only half the job. Organisations should align build credentials, deployment tokens, and runner identities to short-lived, revocable access patterns, then verify that revocation happens as fast as detection.

For practitioners

• Standardise protection at the runner image layer Build custom runner images as governed security artifacts, and require approved image versions for all GitHub-hosted CI/CD jobs. Track image provenance, patch cadence, and rollback readiness so runtime protection is inherited by default.
• Audit workflow coverage for control drift Compare repositories and workflow files against the actual runner image baseline to identify jobs that still rely on per-file security steps. Use that inventory to retire duplicate protections and find pipelines that are still inconsistent.
• Tighten secret scope for build identities Review the secrets, tokens, and deployment credentials available to CI/CD runners, then reduce each one to the minimum scope needed for the job. Prefer short-lived credentials and separate privileged deployment access from routine build execution.
• Treat runner lifecycle as part of identity governance Include runner image updates, policy changes, and agent version changes in change control and access review processes. A runner image that changes without review can quietly alter the effective privileges of every workflow that uses it.

Key takeaways

• Workflow-level runtime protection breaks down at scale because it depends on human consistency rather than enforced execution controls.
• CI/CD runners should be treated as high-risk workload identities because they handle secrets, tokens, and deployment access inside trusted build paths.
• Baking security into custom runner images improves consistency, but only if image governance, secret scope, and revocation are controlled with equal discipline.

Key terms

• Runner image governance: Runner image governance is the control of what is installed, permitted, and trusted in the execution image used by CI/CD jobs. It includes patching, provenance, policy inheritance, and rollback so that security controls are enforced by the platform, not by individual workflows.
• Workflow-level security step: A workflow-level security step is a manual control added to each pipeline definition to provide monitoring or enforcement during job execution. It can work well in small environments, but it becomes brittle when coverage depends on every repository author remembering to include it.
• CI/CD workload identity: CI/CD workload identity is the identity posture of a build or deployment runner, including its secrets, tokens, permissions, and trust boundaries. Treating it as an identity surface makes it easier to apply least privilege, revocation, and separation of duties to automation.
• Runner image governance debt: Runner image governance debt is the accumulation of security risk when organisations manage multiple pipeline protection patterns without a single enforceable baseline. The debt shows up as inconsistent runtime protection, stale agent versions, and unclear ownership of the effective control state.

What's in the full article

StepSecurity's full blog post covers the operational detail this post intentionally leaves for the source:

• Installation and configuration guidance for GitHub-hosted custom runner images with baked-in Harden-Runner
• Migration considerations for teams moving from workflow-by-workflow security to image-level enforcement
• How the agent behaves when a workflow already includes the Harden-Runner step
• Operational notes on using Policy Store enforcement across runner images

👉 The full StepSecurity post covers installation details, migration behavior, and policy enforcement for custom runner images.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and identity lifecycle control. It is designed for practitioners who need to align machine identity controls with broader security and access governance.