CI/CD runtime monitoring is becoming essential for supply chain defense

At a glance

What this is: StepSecurity argues that CI/CD runtime monitoring is becoming essential because trusted pipeline execution is now a high-value attack surface for supply chain abuse and anomalous workflow activity.

Why it matters: For IAM, PAM, and NHI practitioners, this matters because CI/CD runners and workflow identities behave like privileged non-human actors whose actions need runtime oversight, not just static configuration review.

By the numbers:

• StepSecurity says Harden-Runner now protects more than 8,000 open-source repositories.

Context

CI/CD pipelines are the systems that build, test, and ship software, which makes them a sensitive control point rather than a neutral automation layer. When attackers target build infrastructure, they are often seeking trusted execution paths, secrets, or release authority that can be abused without immediately tripping perimeter controls.

This article sits at the intersection of cloud security, supply chain security, and identity governance because runners, actions, tokens, and workflow permissions function as non-human identities in practice. The core problem is not simply monitoring more logs, but governing what privileged automation can do while it is running.

StepSecurity frames the current state as typical of modern development rather than an edge case: pipeline trust has expanded faster than runtime control, and that gap is now being exploited by attackers and exposed by legitimate anomalies.

Key questions

Q: What breaks when CI/CD pipelines are monitored only at configuration time?

A: Configuration-only monitoring misses the actual execution path, which is where secrets are read, commands are launched, and network traffic is generated. A workflow can look clean on paper and still be abused at runtime by a compromised dependency, tampered action, or malicious step. Security teams need behavioural telemetry to catch what the YAML file cannot show.

Q: Why do CI/CD secrets create more risk than many teams expect?

A: CI/CD secrets often have broad blast radius because they can authenticate to source control, cloud platforms, package registries, and deployment systems. If those secrets are long-lived or reused across repositories, one exposure can open several downstream paths. The risk is highest when secrets are stored in workflow contexts where third-party code can read them.

Q: What are the signs that a pipeline workload has been tampered with?

A: Look for network calls to unfamiliar domains, process launches that do not match the job's normal profile, sudden reads of environment secrets, and tag or version changes that happen too quickly to reflect normal release discipline. These signals often indicate that a trusted workflow has been altered or is running unapproved code.

Q: How should security teams govern AI agent spend in CI/CD pipelines?

A: They should treat spend governance as a request-level control problem, not a billing review problem. The gateway should tag every call with owner metadata, track cumulative cost by repo and team, and enforce thresholds with clear alert and fail-closed behaviour. That makes cost overruns actionable and ties accountability to the workload that caused them.

Technical breakdown

Why CI/CD runners now need runtime monitoring

CI/CD runners execute code in a trusted build context, which means they can access secrets, network destinations, artifacts, and signing paths that ordinary application code never should. Static review can confirm what a workflow is configured to do, but it cannot reliably detect what a compromised dependency, malicious action, or manipulated step does at execution time. Runtime monitoring changes the control point from configuration to behaviour. That is the right place to detect secret reads, unusual process launches, suspicious outbound traffic, and tag or workflow tampering. In practice, CI/CD security has become a non-human identity problem because the runner and its credentials are the enforcement surface.

Practical implication: Treat build runners as privileged non-human identities and monitor their live behaviour, not just their YAML definitions.

How behavioural baselines expose supply chain abuse

A behavioural baseline is a record of what a workflow normally does, including network calls, file access, process trees, and credential use. When a pipeline suddenly reaches a new endpoint, starts reading environment variables it never touched before, or changes tag movement patterns, the anomaly is often more revealing than a signature match. This matters in supply chain attacks because malicious code is usually executed inside legitimate automation, using trusted domains and expected tooling. The detection value comes from context: a workflow that still 'succeeds' can nonetheless be compromised if its runtime actions diverge from its historical pattern.

Practical implication: Build anomaly detection around workflow behaviour so you can flag abuse that looks legitimate at the configuration layer.

What AI coding agents change in pipeline trust

AI coding agents extend CI/CD risk because they can create branches, open pull requests, and execute code with machine-granted permissions. That makes them neither traditional users nor simple scripts. They are delegated actors whose activity may be difficult to separate from normal automation unless the pipeline records what they accessed and when. The governance challenge is not whether AI is present, but whether the environment can distinguish intended agent behaviour from misuse, prompt-induced drift, or unauthorized execution paths. That is an identity and privilege problem as much as an AI problem.

Practical implication: Require runtime visibility into agent-generated actions before allowing AI-assisted workflows to touch build or release paths.

Threat narrative

Attacker objective: The attacker aims to convert trusted build execution into secret theft, pipeline manipulation, and downstream supply chain compromise.

1. Entry occurs when a trusted workflow, compromised dependency, or tampered action executes inside the CI/CD runner.
2. Credential access follows when the malicious process reads environment secrets, tokens, or cached credentials available to the job.
3. Impact occurs when the attacker uses those secrets to exfiltrate data, poison downstream builds, or extend access into other repositories and services.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI/CD runtime monitoring is now a governance control, not a developer convenience. The article shows that build systems have become privileged execution environments with secrets, tokens, and release authority attached. That makes runtime observation a control-layer issue, not just an operational enhancement. For identity teams, the key shift is recognising runners and workflow identities as governed actors whose actions must be continuously verified.

Pipeline trust has outgrown static configuration review. Workflow files, pinned dependencies, and code review still matter, but they do not reveal what a compromised step does once execution starts. The article's examples show why detection must move closer to runtime behaviour, especially where secrets and external network access are involved. Practitioners should treat execution telemetry as part of the control plane for supply chain defence.

CI/CD is now an NHI governance problem as much as a cloud security problem. Runners, actions, bot tokens, and workflow permissions are non-human identities with lifecycle, scope, and monitoring requirements. StepSecurity's framing reinforces a broader point: if an automation identity can read secrets or trigger release paths, it needs the same kind of accountability as any other privileged actor. The right unit of control is the job session, not the repository alone.

Runtime monitoring closes the gap between intended and actual privilege use. A workflow may be approved, but still behave in ways no reviewer expected once dependencies or tags change. That is the control gap supply chain attackers exploit. The practical conclusion for security programmes is to govern CI/CD based on observed execution, not just declared policy.

From our research library:

• 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.
• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

CI/CD runtime monitoring is becoming a detection layer for secret sprawl in motion. Static controls tell you where secrets should live, but they do not show when a workflow reads credentials in an unexpected execution path. That is why runtime telemetry belongs alongside secrets governance, especially when pipelines are trusted to handle release-critical access.

CI/CD pipelines now behave like privileged non-human identities with a short but dangerous execution window. The governance problem is not only whether a runner is authorised, but whether its actual behaviour matches that authorisation during the job session. As CI/CD and AI-assisted workflows converge, the control point moves to runtime observation and lifecycle accountability.

Pipeline identity debt: the longer teams rely on trusted automation without runtime visibility, the more exposure they accumulate in jobs, tokens, and delegated build permissions. Security programmes should prepare for a model where build-time behaviour is reviewed as carefully as human administrative access.

For practitioners

• Instrument CI/CD jobs with runtime behaviour monitoring Track process execution, file access, network calls, and secret reads inside build jobs so deviations from normal workflow behaviour are visible in real time.
• Classify build runners as privileged non-human identities Assign ownership, scope, and review requirements to runners, actions, and bot tokens so their permissions are managed as part of identity governance.
• Alert on unusual secret access from trusted workflows Detect when a job touches credentials, environment variables, or service endpoints it has never used before, especially during package install or release steps.
• Investigate tag movement and dependency drift as compromise signals Treat create-delete-recreate tag patterns, unexpected version changes, and dependency swaps as indicators of potential supply chain tampering.
• Extend controls to AI-assisted pipeline activity Require visibility into actions taken by coding agents before they can create branches, open pull requests, or execute build steps that affect release integrity.

Key takeaways

• CI/CD pipelines have become privileged execution environments, so runtime monitoring is now part of supply chain defence rather than an optional visibility feature.
• The article's milestone data shows broad adoption, with more than 8,000 protected repositories and over 8 million jobs monitored weekly.
• Security teams should govern runners, tokens, and AI-assisted workflow activity as non-human identities and verify what they do while jobs are running.

Key terms

• CI/CD runner: A CI/CD runner is the execution environment that performs build, test, or deployment jobs. It often has access to source code, tokens, and cloud credentials, which makes it a high-value identity surface when workflows are compromised.
• Runtime Monitoring: The practice of observing identity activity while it is happening, not after the fact. For agents and NHIs, it means tracking tool calls, credential use, and resource access in real time so deviations from approved scope can be detected before damage compounds.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.
• Supply Chain Defence: Supply chain defence is the set of controls used to protect organisations from risk introduced through suppliers, software dependencies, and external service relationships. It depends on visibility, trust verification, and the ability to act quickly when a partner's posture changes.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners turn delegated access into a governed control model across modern automation.