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

At a glance

What this is: StepSecurity argues that CI/CD security now depends on EDR-style runtime monitoring because build pipelines are a live attack surface, not just a deployment mechanism.

Why it matters: For IAM and NHI teams, this matters because CI/CD runners, secrets, and AI-generated workflows all create identity and privilege exposure that conventional pre-execution controls can miss.

By the numbers:

• StepSecurity says Harden-Runner is protecting more than 8,000 repositories.

👉 Read StepSecurity's analysis of CI/CD runtime monitoring and pipeline supply chain defence

Context

CI/CD pipelines are increasingly part of the production trust boundary, which means compromise can begin before software reaches a runtime environment. In practice, the risk sits in the runner, the workflow, the secret, and the identity behind the automation, not only in the deployed application. The article uses that problem space to argue that pipeline security needs runtime observation, especially where secrets and delegated access are involved.

That framing is relevant to identity security because CI/CD systems rely on service accounts, tokens, ephemeral credentials, and automated actions that behave like non-human identities. Once those identities are embedded in workflows, attackers can exploit them for secret theft, package tampering, or downstream access. The article's position is typical of the current market shift: security teams are treating build-time behaviour as a governance problem, not just a DevSecOps concern.

Key questions

Q: How should security teams reduce risk from secrets in CI environments?

A: They should minimise the number of long-lived credentials available to build jobs, use short-lived scoped tokens where possible, and treat runners as privileged systems. Every pipeline should have a clear revocation path so that exposed secrets can be invalidated quickly when compromise is suspected.

Q: Why do CI/CD pipelines create non-human identity risk?

A: CI/CD pipelines create non-human identity risk because they authenticate to other systems, carry secrets, and perform privileged actions automatically. When a workflow is compromised, the attacker can inherit that authority and move into cloud, source control, or publishing systems. The pipeline is therefore an identity-bearing control point, not just an execution engine.

Q: What do teams get wrong about supply chain protection in build systems?

A: Teams often focus on code integrity alone and overlook the runtime actions of the build job itself. That leaves a gap where malicious workflows can read secrets, call external infrastructure, or alter artifacts even when the repository and dependency checks appear clean.

Q: Who is accountable when an AI agent or workflow modifies a release pipeline?

A: Accountability should rest with the system owner who approved the automation path, not with the agent or the pipeline alone. Organisations need explicit ownership for workflow identities, release permissions, and audit trails so that changes can be traced to a responsible team and governed before production impact.

Technical breakdown

Why CI/CD runners need runtime monitoring

CI/CD runners execute untrusted code paths inside trusted pipelines, which makes them attractive for supply chain attackers. Static checks can validate configuration and dependencies, but they cannot see live behaviour such as unexpected network calls, process spawning, or secret access. Runtime monitoring closes that gap by observing execution as it happens and flagging behaviour that deviates from the pipeline baseline. In identity terms, the runner becomes an execution principal with sensitive access, so the control problem is not only code integrity but also what that principal is allowed to do during the job.

Practical implication: monitor runner behaviour in-line so anomalous execution is visible before secrets or artifacts are exfiltrated.

How compromised workflows turn into secrets exposure

A compromised workflow can read environment variables, access tokens, cloud credentials, and deployment keys if those values are available at runtime. Attackers do not need to break the whole environment if they can hijack a single job with broad permissions or a weakly scoped secret. This is why secrets management and workload identity governance matter together: the secret is only one part of the control plane, while the workflow's effective privilege determines blast radius. If the pipeline can reach sensitive systems, the attacker can often do the same once code execution is achieved.

Practical implication: scope workflow credentials tightly and remove any secret that a job does not need to complete its task.

Why AI coding agents change CI/CD security assumptions

AI coding assistants that can create branches, open pull requests, and run code introduce a new class of automation that behaves like a non-human identity. The risk is not simply that the agent writes code, but that it can participate in pipeline execution with delegated permissions and unclear intent boundaries. That creates governance pressure around attribution, approval, and runtime oversight because the security team may not be able to distinguish ordinary agent activity from manipulated or unsafe behaviour without telemetry. The result is a stronger need to treat agent-generated workflow actions as part of the identity and access model.

Practical implication: assign explicit ownership and runtime observation to AI-generated workflow actions before they can touch build or release systems.

Threat narrative

Attacker objective: The attacker wants to turn trusted build infrastructure into a credential-harvesting and supply chain compromise path that scales across many repositories.

1. Entry occurs when attackers exploit compromised dependencies, malicious GitHub Actions, or poisoned workflow inputs inside a trusted CI/CD pipeline.
2. Escalation happens when the workflow inherits secrets, tokens, or build permissions that allow the attacker to move from code execution to credential abuse.
3. Impact follows when those credentials are used to steal secrets, tamper with builds, or exfiltrate artifacts across repositories and downstream systems.

NHI Mgmt Group analysis

CI/CD pipelines now function as non-human identity environments, not just build systems. Once workflows carry secrets, tokens, and cloud access, the runner becomes an identity-bearing execution context that deserves the same governance discipline as service accounts or privileged automation. The article correctly highlights runtime monitoring, but the deeper issue is identity sprawl inside delivery pipelines. Practitioners should treat every workflow principal as a governed non-human identity.

Runtime visibility is the control gap that separates theory from containment. Static scanning can reduce misconfiguration, but it cannot reliably expose live abuse such as secret reads, outbound callbacks, or payload staging. That is why EDR-style telemetry for CI/CD is gaining traction: it gives defenders a chance to see malicious behaviour while the job is still active. Teams should regard pipeline runtime data as a core detection source, not an optional supplement.

Secret exposure inside pipelines is really a privilege design problem. If a job can reach production credentials, then the blast radius is set long before an attacker arrives. OWASP NHI guidance and MITRE ATT&CK both point to the same pattern: credential access becomes decisive when runtime identity is over-scoped. The practical conclusion is that secrets inventory, job-level least privilege, and revocation need to be designed together.

AI coding agents amplify the same trust problem by adding autonomous execution paths. When an agent can create changes and trigger workflows, the organisation is no longer governing human-authored release activity alone. That creates a governance boundary around agent-generated actions, approval flow, and auditability. Teams should extend IAM and NHI controls to AI-assisted delivery pipelines before those agents become routine contributors to production changes.

CI/CD security is shifting from prevention-only to behaviour-led containment. The market signal here is not that scanning is obsolete, but that security teams need a second control plane for runtime evidence. This aligns with broader zero-trust thinking: trust is not assumed because code entered the pipeline. Practitioners should expect pipeline telemetry, not just policy, to become central to supply chain defence.

What this signals

Pipeline telemetry is becoming part of identity governance. As CI/CD jobs inherit secrets and cloud permissions, organisations need to classify runners and automation accounts as governed non-human identities rather than invisible infrastructure. That shift matters because identity controls that stop at login do not capture what happens during execution, and build-time behaviour can now create the same blast radius as a compromised service account.

Behaviour-based detection will increasingly sit beside secrets management. The useful control is not merely whether a token exists, but whether the job that holds it behaves as expected. That is why runtime monitoring and secret revocation should be paired, with alerting tied to anomalous process creation, network egress, and tag movement. For background on the wider identity risk pattern, see 52 NHI Breaches Analysis.

CI/CD security is converging with NHI governance and agentic AI oversight. AI-generated changes and automated workflows both create identity-bearing actions that need ownership, review, and containment. Teams should expect release systems to become a primary place where NHI policy, workload identity, and AI delegation controls meet, especially as autonomous tooling becomes a routine part of delivery pipelines.

For practitioners

• Instrument runner runtime behaviour Deploy controls that record process launches, network destinations, and file access inside CI/CD jobs so unusual execution is visible in real time. Use that telemetry to detect secret harvesting and workflow tampering before the job completes.
• Reduce workflow privilege scope Audit every GitHub Actions workflow for the minimum secret set, cloud permission, and repository access it actually needs. Remove inherited access from jobs that only require build or test capabilities, and separate release privileges from routine automation.
• Treat workflow identities as governed NHIs Catalogue runners, service accounts, tokens, and automation accounts as part of the NHI estate, then assign ownership, rotation, and offboarding rules. This makes pipeline access reviewable instead of leaving it embedded in YAML and ad hoc secrets.
• Add detections for suspicious dependency and tag movement Alert on workflow tag changes, package version churn, and unexpected dependency behaviour because attackers often use those transitions to smuggle code into trusted pipelines. Tie those alerts to release gates and incident response playbooks.

Key takeaways

• CI/CD pipelines now carry identity risk because workflows, runners, and tokens behave like non-human identities with real access.
• Runtime monitoring matters because the most dangerous supply chain attacks often reveal themselves only during execution, not in static review.
• Teams should govern pipeline identities, reduce privilege scope, and pair secrets management with behaviour-based detection before attackers do it for them.

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.
• 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.
• 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.
• SaaS Supply Chain Attack: A SaaS supply chain attack is an intrusion path that uses trusted integrations, tokens, or third-party services to reach a target environment indirectly. The attacker relies on inherited trust between applications rather than breaking the main system first, which makes detection and containment harder.

What's in the full article

StepSecurity's full blog post covers the operational detail this post intentionally leaves for the source:

• Detection logic and runtime baseline methods used to flag anomalous CI/CD behaviour in GitHub Actions
• Details of the Microsoft Defender runner anomaly and the AWS tag-movement investigation
• Examples of how Harden-Runner responds to compromised packages and malicious workflow execution
• The AI coding-agent security examples that show how workflow telemetry is applied in practice

👉 The full StepSecurity post covers the detection examples, AI workflow risks, and CI/CD protection patterns in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It gives practitioners a practical way to connect identity controls to modern automation and delivery pipelines.