Teams should use a runtime control that observes network connections, process execution, and file writes directly on the runner. That approach reduces blind spots created by platform differences and helps detect suspicious behaviour during CI/CD execution. Consistency matters because the same control should work across hosted and self-hosted runners without forcing separate workflow designs for each operating system.
Monitoring Runners Without Modifying Workflow Logic
Security teams need visibility that sits below the workflow layer because GitHub Actions jobs can be altered, copied, or reused across repositories while the underlying runner behaviour still remains the same. A runtime control that watches process creation, network activity, and file writes gives teams a platform-agnostic view of what the runner actually does during execution. That matters across Linux, Windows, and macOS because the same workflow can behave differently once it reaches the host operating system, especially when third-party actions, scripts, or build tools are involved. For broader control context, NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for mapping monitoring objectives to logging and detection expectations. In practice, many security teams discover runner abuse only after an unexpected outbound connection or post-build file change has already occurred, rather than through deliberate workflow design.
What Runtime Monitoring Sees Across Linux, Windows, and macOS
The practical goal is not to inspect the YAML in detail, but to observe what the job does once execution starts. A workflow step may call a script, invoke a compiler, download dependencies, or launch a helper process. A runtime sensor can record those actions consistently even when the shell, process model, or endpoint telemetry differs by operating system. That gives defenders a stable detection layer for behaviour that matters more than platform syntax.
On Linux, useful signals often include new child processes, outbound requests to unusual destinations, and writes into workspace or temporary paths. On Windows, the same problem may surface through PowerShell execution, command-line spawning, archive extraction, or credential-access activity hidden inside build steps. On macOS, teams often need the same visibility into shell launches, binary execution, and unexpected persistence or staging behaviour. The point is not to make all three platforms look identical, but to normalise the security question: did this runner do something it should not have done?
- Track process trees so a job can be tied to the exact commands it spawns.
- Monitor network destinations, especially new domains, uncommon ports, and download patterns.
- Watch file creation and modification in workspace, cache, and temporary locations.
- Correlate telemetry back to the runner instance so an alert is attributable to one job run.
This approach is especially valuable when organisations use both hosted and self-hosted runners, because the monitoring objective stays the same even if the infrastructure ownership changes. Where it breaks down is when telemetry is too shallow to distinguish ordinary build activity from malicious staging, or when the control cannot maintain enough context to link an action back to the job that triggered it.
Where Cross-Platform Runner Monitoring Gets Hard
Tighter runtime visibility often increases operational overhead, requiring organisations to balance detection depth against noise and performance impact. That tradeoff becomes more visible in CI/CD because normal build jobs are noisy by design: compilers, package managers, test harnesses, and artifact upload steps can all look suspicious if the policy is too blunt.
One common variation is the difference between hosted and self-hosted runners. Hosted runners may be easier to standardise, but they usually provide less room for deep host tuning. Self-hosted runners can deliver richer telemetry, but they also expand the burden of sensor maintenance, update hygiene, and response ownership. Another edge case is workflow reuse through shared actions or composite actions: the workflow file may stay unchanged while the real execution path shifts underneath it. Guidance here is not fully standardised across the industry, so teams should treat deep behavioural monitoring as a defensive pattern rather than a universally prescriptive design.
Platform-specific quirks also matter. macOS signing and launch behaviour can complicate interpretation, Windows script execution may be heavily mediated by administrative tooling, and Linux containers can blur where the job ends and the host begins. A team that relies only on logs from the workflow engine will miss these differences. A team that relies only on endpoint alerts may miss the job context needed to judge whether the behaviour is expected. The strongest approach combines job attribution, host telemetry, and a narrow set of detections that are tuned to CI/CD execution patterns.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 8.2 — Audit Log Management | Cross-platform runner telemetry needs consistent log collection and retention. |
| 8.7 — Email and Web Browser Protections | Runner monitoring often depends on watching web downloads and outbound activity during jobs. | |
| 10.1 — Malware Defenses | Behavioural monitoring on runners helps detect malicious execution during CI/CD runs. | |
| Recommendation — Centralise runner logs and preserve them long enough to investigate suspicious CI/CD activity. Restrict and monitor web-driven download paths used by build jobs and actions. Use runtime detection to identify suspicious processes and payload staging on runners. | ||
| NIST CSF 2.0 | DE.CM-01 — The network is monitored to detect potential cybersecurity events | Runner network activity is a core signal for spotting suspicious CI/CD behaviour. |
| DE.CM-07 — Monitoring for unauthorized personnel, connections, devices, and software is performed | CI/CD runners need monitoring for unexpected processes, software, and connections. | |
| DE.CM-09 — Computing hardware, software, and workloads are monitored to find potential cybersecurity events | Runners are workloads whose runtime behaviour must be watched across OS platforms. | |
| Recommendation — Monitor runner network traffic for unusual destinations, ports, and downloads. Alert on unapproved runner processes, tools, and outbound connections during job execution. Instrument runner workloads so file, process, and network activity are visible in one control. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | GitHub Actions jobs often execute scripts that can be abused across OS-specific shells. |
| T1105 — Ingress Tool Transfer | Monitoring downloads and staging on runners helps detect payload transfer during builds. | |
| T1106 — Native API | Agentless or low-level runtime activity can surface through OS-native process and file behaviour. | |
| Recommendation — Map runner script execution to T1059 and investigate unexpected shell or PowerShell activity. Hunt for suspicious tool transfers and staged binaries arriving during workflow execution. Correlate native process behaviour with job context to spot host-level abuse in runners. | ||
Practitioner Guidance
What to prioritise: Build one behavioural monitoring baseline that applies to all runner OS types, then tune exceptions by trusted build pattern rather than by platform. That keeps the control aligned with the actual abuse surface instead of splitting effort across three separate policy designs.
What to verify: Confirm the control can attribute network, process, and file activity back to a single job run with enough fidelity to support triage. If it cannot join those signals, it will produce alerts that are hard to investigate and easy to ignore.
What good looks like: Security teams can tell whether a runner downloaded, executed, or staged something unusual without changing workflow logic, and they can do it consistently on Linux, Windows, and macOS.
Practitioner takeaway: Cross-platform runner monitoring works best when it is treated as an execution-visibility problem, not a YAML-governance problem; the control should explain what the job did, not merely what the workflow intended.
Related resources from NHI Mgmt Group
- How can teams decide whether to centralise developer machine security controls across Linux, macOS, and Windows?
- How should security teams implement GitHub Actions SHA pinning across a large repository estate?
- How do security teams compare model cost, latency, and output quality across providers without building a separate evaluation workflow?
- How should security teams enforce guardrails across AI gateways and agent actions without wiring each application separately?
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
