Static checks can miss attacks that appear only during execution, especially when a trusted workflow is modified through dependency compromise or injected commands. Runtime monitoring helps identify unexpected outbound connections, unusual processes, and unauthorized file writes as they happen. That makes it a stronger control for spotting supply chain compromise than code review alone.
Why runtime monitoring changes the security model for CI/CD
Static checks and repository review are good at finding what is already visible in source, configuration, and dependency metadata. They are weaker once a pipeline starts executing code, resolving dependencies, or calling external services, because the real security boundary becomes the running job, its network activity, and the files it creates or alters. That is why runtime monitoring matters for supply chain defence: it observes behaviour that code review cannot prove in advance. NIST’s control families on auditing, monitoring, and system integrity reflect this same need for post-change visibility in operational environments. In practice, many security teams discover pipeline abuse only after a trusted workflow has already executed unexpected commands or touched assets it should never have reached.
What runtime monitoring sees that static validation cannot
CI/CD pipelines often look trustworthy on paper because the repository commit, review history, and dependency manifest appear clean. The weakness is that a pipeline can still be manipulated at execution time through compromised dependencies, altered build steps, injected parameters, hostile scripts, or unexpected tool behaviour. Runtime monitoring focuses on the evidence that exists only while the job is live: process starts, shell invocation patterns, outbound connections, secret access, privilege use, file-system changes, and artifact creation.
That distinction matters because a trusted workflow can still become an attack path. A malicious dependency may only trigger after install. A build step may download content from an unexpected domain. A script may write to locations outside the normal workspace. Repository review can confirm intent, but it cannot prove that the execution path stayed aligned with that intent once the runner began processing inputs and dependencies. For that reason, runtime monitoring is not a replacement for static controls; it is the layer that detects when the execution reality diverges from the approved pipeline design.
- Use static checks to reduce obvious defects before merge.
- Use runtime telemetry to detect behaviour that only appears after execution begins.
- Treat unexpected network access, child processes, and file writes as indicators of pipeline drift.
- Correlate runtime events with job identity, runner context, and dependency activity.
For a useful baseline on control objectives around monitoring and integrity, NIST SP 800-53 Rev 5 Security and Privacy Controls is the most directly relevant public reference. Where teams stop at commit review alone, they are effectively trusting that no attacker can change the meaning of a safe-looking pipeline during execution.
When static checks are enough and when they are not
Tighter pipeline control often increases engineering overhead, requiring organisations to balance speed against the depth of observation they want during builds and deployments. Static review is often sufficient for low-risk internal jobs, heavily locked-down scripts, and workflows that never touch sensitive credentials or untrusted inputs. It becomes insufficient when the pipeline executes third-party code, handles secrets, produces deployable artifacts, or operates across multiple trust boundaries.
The common mistake is to treat static validation as if it covered runtime abuse by default. It does not. Static analysis can confirm that a workflow file matches expectations, but it cannot prove that a dependency downloaded at build time is benign, that a runner was not redirected, or that a step did not spawn an unexpected process. Guidance is more consistent than consensus on one point: if the pipeline can fetch, unpack, execute, or publish anything dynamically, then runtime observation is part of the control surface, not an optional enhancement.
Where this guidance breaks down is in environments that cannot collect trustworthy telemetry from the runner or artifact path. If the platform cannot expose process, network, or file activity with enough fidelity, the organisation must compensate with stricter execution isolation and stronger provenance controls rather than assuming static review is enough.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 — Monitoring for Unauthorized Events | CI/CD runtime monitoring detects unexpected execution and network activity. |
| PR.DS-6 — Integrity Checking Mechanisms | Runtime checks help detect when trusted build paths diverge during execution. | |
| Recommendation — Monitor pipeline runtime events for unauthorized processes, connections, and file changes. Validate build and artifact integrity during execution, not only before merge. | ||
| CIS Controls v8 | 8 — Audit Log Management | Pipeline monitoring depends on collecting and retaining runner telemetry. |
| 10 — Malware Defenses | Runtime observation helps detect malicious code that static review missed. | |
| Recommendation — Centralise runner and workflow logs so suspicious build behaviour can be reviewed. Inspect executed pipeline activity for malicious behaviour that slips past static checks. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | The question concerns compromise that emerges during trusted pipeline execution. |
| Recommendation — Map suspicious pipeline events to supply-chain compromise techniques and hunt for execution-stage abuse. | ||
Practitioner Guidance
What to prioritise: Start by monitoring the highest-risk pipeline stages, not every job equally. Build, test, release, and artifact-publishing steps deserve the most scrutiny because they are where untrusted code, secrets, and external fetches converge.
What to verify: Confirm that alerts are tied to the actual runner identity, command context, and outbound destination. A useful control distinguishes expected package retrieval from unexpected egress, and expected build tooling from arbitrary shell activity.
Common mistake: Teams often tune runtime monitoring only for known malware signatures, which misses the more common failure mode in CI/CD: legitimate tooling doing something in an illegitimate context.
Practitioner takeaway: The real decision is not whether static controls are useful, but whether the pipeline has enough live telemetry to prove that trusted code stayed trusted once execution began.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
