Notifications
Clear all
Topic starter
19/08/2026 4:04 pm
TL;DR: Runtime protection can start with the VM instead of being added workflow by workflow when organisations bake Harden-Runner into GitHub-hosted runners using GitHub’s custom runner images, according to StepSecurity. That shifts CI/CD security toward platform-level enforcement, where policy consistency and runner lifecycle control matter more than developer memory.
NHIMG editorial — based on content published by StepSecurity: Back to Blog Product Bake Harden-Runner Into GitHub's Custom Runner Images for Organization-Wide CI/CD Security
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read StepSecurity's post on baking Harden-Runner into GitHub custom runner images →
GitHub custom runner images: are your CI/CD controls keeping up?
Explore further
19/08/2026 4:38 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: GitHub custom runner images shift CI/CD runtime security left
