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.
Editorial analysis by NHI Mgmt Group, based on content published by StepSecurity: “Bake Harden-Runner Into GitHub's Custom Runner Images for Organization-Wide CI/CD Security”.
Key questions
Q: What breaks when CI/CD runtime protection depends on every workflow including the same step?
A: Governance consistency breaks first, followed by coverage drift.
Q: Why do GitHub-hosted runners need stronger governance than ordinary build machines?
A: They often hold cloud secrets, source code, and release permissions, so a runner compromise can affect build integrity and downstream delivery.
Q: What are the signs that CI/CD security controls are not working well enough?
A: Common warning signs include secrets appearing in code or adjacent collaboration tools, policy violations that remain unresolved, weak visibility across the pipeline, and scanners that miss misconfigurations until late.
Practitioner guidance
- Bake runtime protection into custom runner images Include the runtime security agent in the base image used by GitHub-hosted runners so every job inherits protection without per-workflow edits.
- Govern runner images as security assets Track image ownership, versioning, patching, and retirement so the security posture of the runner fleet stays consistent across repositories.
- Audit workflows for legacy per-job controls Find workflows that still rely on manually inserted security steps and use image-level deployment to retire that operational dependency.
Bottom line: CI/CD runtime protection becomes more reliable when it is embedded in the runner image rather than added separately to every workflow.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:38 pm
Runner images are becoming the real policy boundary for CI/CD security. When runtime protection depends on workflow authors remembering a step, governance will eventually fragment across repositories and teams. Moving the control into the image changes the enforcement point from developer behaviour to platform lifecycle management. That is a better fit for enterprise CI/CD, where consistency matters more than local convenience. Practitioners should treat runner images as governed security assets, not just build runtime plumbing.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should organisations handle CI/CD security when they already have many workflows in production?
A: Use a migration path that preserves existing pipelines while shifting the control into the runner image. That lets teams keep delivery stable, avoid mass workflow rewrites, and steadily reduce dependence on per-file security steps as the image becomes the default enforcement layer.
👉 Read our full editorial: GitHub custom runner images shift CI/CD runtime security left