Why do CI/CD pipelines need runtime monitoring instead of relying only on static checks and repository review?

Why This Matters for Security Teams

CI/CD pipelines are not just build systems. They are privileged execution environments that can fetch dependencies, run scripts, sign artifacts, publish packages, and reach internal services. Static checks and repository review are necessary, but they only evaluate what is present in code or configuration before execution. They cannot reliably detect supply chain compromise that appears at runtime, such as a malicious post-install script, an injected command, or a trusted action turning hostile after dependency resolution.

That gap is why runtime monitoring belongs in the control stack alongside pre-merge scanning. NIST SP 800-53 Rev 5 Security and Privacy Controls frames continuous monitoring as part of effective security operations, and NHIMG research on the CI/CD pipeline exploitation case study shows how quickly a trusted workflow can become an attacker’s execution path. Static review can confirm intent; it cannot confirm behaviour after the runner starts.

In practice, many security teams discover pipeline abuse only after outbound traffic, secret access, or artifact tampering has already occurred, rather than through intentional review.

How It Works in Practice

Runtime monitoring adds visibility to the execution layer of the pipeline. Instead of asking only whether a job definition looks safe, teams watch what the job actually does: child processes spawned, files written, network destinations reached, credentials read, and system calls that should not occur in a normal build. That is especially important when workflows use third-party actions, ephemeral runners, or package install hooks, because those are common points where trusted code is replaced or behaviour changes dynamically.

Operationally, the strongest patterns combine pre-execution controls with live detection. For example, repository review and static analysis can block obvious risky changes, while runtime controls can detect unexpected egress to unfamiliar domains, privilege escalation inside the runner, or attempts to touch signing keys and release artifacts. This is consistent with guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls, which treats monitoring as a control objective rather than an optional afterthought.

• Instrument runners to log process trees, network connections, and file modifications.
• Alert on unexpected use of secrets, token minting, or artifact signing steps.
• Constrain outbound access so the pipeline can only reach approved repositories, registries, and APIs.
• Correlate runtime events with the workflow commit, dependency version, and job identity.

The NHIMG Guide to the Secret Sprawl Challenge is relevant here because pipelines often become secret-handling systems without being designed that way. Runtime monitoring helps identify when those secrets are exposed or misused during execution. These controls tend to break down in highly ephemeral serverless runners with limited telemetry, because there is too little process and network visibility to reconstruct what the job actually did.

Common Variations and Edge Cases

Tighter runtime monitoring often increases pipeline latency, alert volume, and engineering overhead, so organisations have to balance assurance against build speed and operator fatigue. Best practice is evolving, not settled, especially for teams that rely heavily on vendor-hosted CI services or nested build systems.

Some environments need different thresholds. High-assurance release pipelines may justify deep inspection of every network call and file write, while lower-risk internal builds may focus on only the most sensitive events, such as secret access or signing activity. Teams that use reusable workflows, package registries, or build-from-source dependencies should pay particular attention to transitive execution paths, because the compromise may be one step removed from the repository under review.

NHIMG’s Reviewdog GitHub Action supply chain attack is a useful reminder that trusted automation can become the attack vector itself. Static checks remain valuable, but they are not enough when the real risk is a runtime change in behaviour. Current guidance suggests treating pipeline monitoring as part of the release control plane, not just a detection add-on.

Related resources from NHI Mgmt Group

• When should organisations add runtime controls for AI agents instead of relying on monitoring?
• What breaks when CI/CD pipelines rely on static secrets?
• What breaks when CI/CD pipelines rely on static YAML alone?
• What fails when static credentials are used in CI/CD pipelines?