CI/CD runtime security is becoming a default control for build pipelines

At a glance

What this is: This is a StepSecurity milestone post about Harden-Runner reaching 10,000 protected repositories and the growing case for runtime security in CI/CD pipelines.

Why it matters: It matters because pipeline protection now intersects with secrets governance, workload identity, and privileged automation, all of which can be abused when build systems are trusted by default.

By the numbers:

• StepSecurity says Harden-Runner monitors over 13 million jobs weekly across open source and enterprise environments.

👉 Read StepSecurity's analysis of Harden-Runner's 10,000-repository milestone

Context

CI/CD runtime security addresses a basic governance gap: build pipelines often execute with broad trust, yet they process tokens, secrets, and automation permissions that can be abused at runtime. In practice, this means the pipeline itself becomes an access surface, not just a delivery mechanism.

StepSecurity's milestone matters because it shows the industry moving from static pipeline hardening toward continuous monitoring of workflow behaviour. That has direct implications for NHI governance, especially where build tokens, service credentials, and federated access are used inside automated delivery paths.

The article's starting position is typical for organisations that have already experienced supply chain pressure, but atypical for teams that still treat CI/CD as a low-risk internal process.

Key questions

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. The failure is not only malware execution. It is the combination of broad permissions, weak egress visibility, and secrets that remain usable inside the workflow long enough to be stolen.

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. If those identities have standing credentials or overbroad scopes, patch automation can become a privileged attack path. The security issue is not just the software artefact, but the identity permissions that move that artefact through production.

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. If telemetry shows attempted outbound calls, credential access, or policy violations being blocked or alerted on, the control is operating. If you only see clean workflow files, you do not yet know whether runtime guardrails are effective.

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.

Technical breakdown

Why CI/CD runners need runtime monitoring

CI/CD runners execute code, fetch dependencies, authenticate to registries, and often reach cloud services, which makes them dynamic execution environments rather than simple batch jobs. Runtime security watches what the workflow actually does while it runs, including process creation, network egress, file access, and token use. That matters because malicious behaviour often appears only after a trusted action, package, or script starts executing. Static review can confirm declared logic, but it cannot reliably detect a compromised dependency that changes behaviour at runtime.

Practical implication: monitor workflow behaviour during execution, not only before merge or publish.

How pipeline secrets and tokens get abused

CI/CD compromise usually succeeds when an attacker reaches a runner that already holds high-value credentials or can mint them on demand. That can include GitHub tokens, cloud federation credentials, package publishing rights, or environment secrets. Once those values are exposed, the attacker can tamper with releases, pull private data, or pivot into adjacent systems. The important control question is not whether secrets exist, but whether their use is bound tightly enough to the specific job, runner, and network path that needs them.

Practical implication: treat every workflow credential as a scoped identity with a short-lived, inspectable blast radius.

Why egress control is central to CI/CD defence

Many supply chain attacks become visible only when a compromised workflow makes an unusual outbound connection. Egress control and anomaly detection work together here: egress policy limits where jobs can reach, while runtime telemetry shows when a job deviates from its normal network pattern. In the article's examples, detection depended on spotting unexpected calls to external domains, API endpoints, and exfiltration paths. That is a strong reminder that pipeline defence is partly a network control problem, not just an application security problem.

Practical implication: baseline outbound traffic for runners and block destinations that are not required for build execution.

Threat narrative

Attacker objective: The attacker wants to turn a trusted build workflow into a credential-harvesting and release-tampering channel.

1. Entry occurs when a trusted workflow, dependency, or action is executed inside a CI/CD runner that already has network access and credentials available.
2. Escalation follows when the malicious code inherits the runner's permissions, exposing tokens, publishing rights, or cloud federation capabilities that were intended for the build job.
3. Impact comes when the attacker uses those credentials to steal secrets, tamper with code, alter releases, or pivot into downstream systems and supply chain consumers.

NHI Mgmt Group analysis

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.

Secrets exposure in pipelines creates a short, high-value attack window that static reviews miss. The compromise often happens after the workflow starts, when a token is already live and the malicious behaviour is hidden inside normal build activity. Standing credential exposure window: this is the specific failure mode where secrets remain usable long enough for an attacker to harvest and reuse them before detection catches up. Practitioners should think in terms of runtime containment and token scope, not only secret storage.

The market is converging on runtime enforcement because trust at pipeline start is no longer sufficient. The repeated pattern across supply chain incidents is that trusted dependencies, trusted actions, and trusted runner contexts are being abused after admission. That validates a shift toward continuous monitoring, egress governance, and central policy enforcement. For teams building on GitHub Actions, the governance question is whether build-time trust is still acceptable in any high-value workflow.

Pipeline defence now depends on whether organisations can observe the full workflow identity lifecycle. A build job may create, use, and discard credentials within minutes, which means access reviews alone are too slow to matter. This is where the intersection with NHI governance becomes explicit: service tokens, federation claims, and ephemeral secrets all need lifecycle controls that match machine speed. Teams that cannot see the lifecycle cannot govern the risk.

Runtime telemetry is becoming the evidence layer for supply chain accountability. Security teams need to know which action, process, and outbound connection created an exposure, because incident response in CI/CD is forensic as well as preventative. The practical conclusion is clear: if a platform cannot explain what a runner did, it cannot reliably prove the pipeline was safe.

What this signals

Standing privilege in pipelines is becoming harder to justify. As workflow telemetry gets better, the gap between what a job is allowed to do and what it actually does becomes easier to prove. That shifts programme priorities toward least privilege for runners, tighter federation scopes, and evidence-driven response across build and release paths.

Secrets governance and CI/CD security are converging into the same control problem. The same credentials that unlock deployments also enable exfiltration if a workflow is compromised. Teams should expect more pressure to connect secret lifecycle management, workflow identity, and anomaly detection into one operational view rather than separate tooling silos.

Build security is now part of supply chain resilience, not a niche DevOps concern. The organisations that will cope best are the ones that can explain, baseline, and interrupt runner behaviour across every environment where software is built. For teams that still rely on trust at admission, the risk is no longer theoretical.

For practitioners

• 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. Link those identities to owners and rotation paths.
• 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.
• Centralise detection and triage for workflow anomalies Send runner telemetry into your SIEM and alert on unexpected process trees, token usage, or package-install behaviour so that exfiltration attempts surface before release tampering completes.

Key takeaways

• CI/CD pipelines are high-value identity and secrets targets, not just delivery tools.
• Runtime telemetry matters because compromised workflows often behave normally until the moment they exfiltrate or tamper.
• The strongest control shift is toward short-lived credentials, egress governance, and continuous workflow monitoring.

Key terms

• CI/CD security testing: The use of automated security checks inside continuous integration and continuous deployment pipelines. This includes tools that evaluate code, running applications, and interactive behaviour so vulnerabilities can be found and blocked before deployment becomes irreversible.
• Workflow Identity: A workflow identity is the non-human identity represented by an automated CI/CD process when it authenticates, accesses secrets, or performs actions in other systems. In practice, it is the authority carried by the pipeline itself, and it must be governed with explicit scope, review, and revocation.
• Standing Credential Exposure Window: A standing credential exposure window is the period during which a long-lived secret remains usable after it has been created, exposed, or forgotten. The longer that window stays open, the more likely an attacker can reuse the credential for access, lateral movement, or persistence before the organisation notices.
• Egress Governance: Egress governance is the control of where systems are allowed to send outbound traffic, combined with detection when behaviour changes. In CI/CD, it helps reveal or block exfiltration attempts because malicious actions often become visible only when they reach unusual destinations.

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.

👉 StepSecurity's full post covers the detection patterns, deployment expansion, and workflow controls behind the milestone.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners designing safer automation paths. It helps security and platform teams connect identity lifecycle controls to real operational risk.