Notifications
Clear all
Topic starter
19/08/2026 3:59 pm
TL;DR: CI/CD pipelines need runtime security because trusted workflows, not just code, are increasingly targeted, according to StepSecurity. That shift in supply chain defence pushes teams toward continuous inspection, egress control, and secrets-aware monitoring rather than static trust assumptions, while Harden-Runner now protects more than 10,000 open-source repositories and monitors over 13 million jobs weekly.
NHIMG editorial — based on content published by StepSecurity: 10,000 Open-Source Projects Now Secured by Harden-Runner Community-Tier
By the numbers:
- StepSecurity says Harden-Runner monitors over 13 million jobs weekly across open source and enterprise environments.
Questions worth separating out
Q: What breaks when CI/CD runners are trusted by default?
A: When runners are trusted by default, a compromised action or dependency can inherit credentials, reach sensitive services, and tamper with build outputs without tripping basic access controls.
Q: Why do build and release pipelines create identity risk in supply chain security?
A: Because they are governed by non-human identities with broad access to code, registries, and deployment systems.
Q: How do teams know if agentic CI/CD controls are actually working?
A: Look for evidence that the agent cannot reach secrets, cannot mutate protected branches, and cannot execute shell commands outside its declared boundary.
Practitioner guidance
- Map runner identities and permissions Inventory every CI/CD runner, GitHub token, federation trust, and publishing credential, then classify which jobs can reach privileged systems or sign artefacts.
- Enforce egress allowlists for build jobs Permit only the outbound domains and API endpoints required for the workflow, and block or alert on unexpected access to external hosts, raw file endpoints, and package mirrors.
- Shorten the lifetime of pipeline credentials Use narrowly scoped, job-bound credentials wherever possible, and remove standing secrets from workflows that can rely on ephemeral tokens or federated access.
What's in the full article
StepSecurity's full post covers the operational detail this post intentionally leaves for the source:
- How Harden-Runner detects suspicious process and network behaviour inside GitHub Actions workflows.
- The specific real-world incidents StepSecurity says were caught before public disclosure, including compromise patterns and telemetry clues.
- Implementation changes across GitHub-hosted, self-hosted VM, and Kubernetes-based runners that affect deployment design.
- The community-tier adoption context behind the 10,000-repository milestone and the team’s roadmap for macOS and Windows runners.
👉 Read StepSecurity's analysis of Harden-Runner's 10,000-repository milestone →
CI/CD runtime security is becoming the governance gap teams must close?
Explore further
19/08/2026 4:36 pm
CI/CD runtime security is now an identity control as much as a code control. Build systems do not just run code, they present authenticated identities to registries, cloud services, and downstream automation. That makes workflow tokens, runner permissions, and federation paths part of the identity plane. NIST SP 800-53 access control and audit concepts apply here, but the operational lesson is broader: if a runner can act, it must be treated like a governed workload identity, not a disposable task.
A question worth separating out:
Q: Who is accountable when a supply chain compromise spreads through trusted credentials?
A: Accountability usually spans release engineering, platform security, and identity governance because the incident crosses multiple trust domains. The practical question is which team owns credential scope, publish rights, and offboarding for automation identities. Frameworks such as NIST CSF and NHI governance models help assign control ownership where a single compromise can affect many systems.
👉 Read our full editorial: CI/CD runtime security is becoming a default control for build pipelines
