Process-based detections use runner activity, rather than network telemetry alone, to identify dangerous behaviors during pipeline execution. They can surface memory reads, reverse shells, and privileged container launches that suggest active abuse or post-exploitation activity. This gives defenders a deeper view into what code is actually doing on the runner.
Expanded Definition
Process-based detections focus on what a process does while a job, build, or workload is running, rather than inferring safety from network activity alone. The term is used in pipeline and runner security to describe detection logic that watches execution behavior, such as child process creation, suspicious command invocation, memory access, or privilege changes. That matters because many abusive actions appear normal at the transport layer but are abnormal in the execution layer.
The boundary is important: process-based detections are not the same as generic endpoint monitoring, and they are not limited to malware signatures. They are a behavioural view of execution, which makes them useful in CI/CD runners, ephemeral build agents, and other short-lived systems where traditional tooling may miss the full sequence of activity. The practical distinction is that defenders are judging intent from runtime actions, not from a single file hash or connection event.
For a broader governance frame, NIST’s Cybersecurity Framework 2.0 helps place detection telemetry inside a wider monitoring and response capability, but the process-based lens is narrower and more operational.
Examples and Use Cases
Process-based detections are most useful when runners are trusted to execute code from many sources, but defenders still need to distinguish legitimate automation from abuse.
- A CI job launches a shell that spawns an unexpected downloader, which signals a possible post-exploitation chain rather than normal build activity.
- A containerized runner attempts memory reads from another process, which may indicate credential theft, instrumentation abuse, or malicious inspection.
- A privileged container launch occurs in a pipeline stage that should not require host-level access, suggesting policy drift or abuse of excessive permissions.
- A build step invokes utilities that are rare for that workflow, such as archive extraction followed by lateral command execution, which can expose staging behavior.
- A runner creates an outbound reverse shell while the job is still active, which is a strong sign that the execution environment has been turned into an interactive foothold.
The main tradeoff is noise: aggressive process telemetry can surface legitimate tooling that looks unusual outside its workflow context. Effective use depends on understanding the normal process tree for each runner class and on separating expected orchestration from suspicious delegation or break-out behavior.
Security Implications
When process-based detections are weak or absent, defenders often see only the final network effect and miss the local abuse that made it possible. That creates a blind spot for shell spawning, code injection, process masquerading, and privilege escalation that occurs inside ephemeral infrastructure. In practice, the failure is not just missed detection; it is delayed containment, because investigators lack the execution trail that explains how the runner was used.
This matters especially in build and automation environments where an attacker may only need a short window to read secrets, launch a privileged helper, or pivot into adjacent systems. A process view can reveal the difference between a normal pipeline failure and an active compromise. Common symptoms include unexpected parent-child relationships, short-lived command chains, or sensitive process access from software that has no legitimate reason to inspect them.
For NHIMG readers, the practical takeaway is that runtime visibility is often the only way to prove whether a runner merely executed code or was actively repurposed as an attacker-controlled execution point.
Domain and Governance Relevance
In the primary cybersecurity domain, process-based detections are part of execution-layer monitoring: they help confirm what code actually did, not just where it connected. That makes them especially valuable where network telemetry is incomplete, encrypted, or easy to evade. They also support incident triage by showing whether suspicious activity is isolated to one step or spread across a workflow.
Where this term intersects with identity and access control, the meaning changes in one important way: runner activity can expose whether a workload, build agent, or automation account is being used within its intended authority. That is not because the term becomes an identity concept, but because execution traces often show privilege misuse more clearly than authentication logs do. For governance, the key question is whether the runner is allowed to perform the actions its process tree reveals.
Process-based detections therefore sit at the boundary between detection engineering and control assurance. They help organisations validate that execution boundaries, privilege limits, and approval assumptions are actually holding during live operation.
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, CIS Controls v8 and NIST IR 8596 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM — Security Continuous Monitoring | Process-based detections are continuous monitoring of runner execution behavior. |
| Recommendation — Instrument runner telemetry to detect suspicious process activity during execution. | ||
| CIS Controls v8 | 8 — Audit Log Management | Process telemetry must be collected and retained to support detection and review. |
| Recommendation — Centralize process logs so analysts can investigate runner abuse after execution. | ||
| MITRE ATT&CK | T1055 — Process Injection | Process-based detections often surface process manipulation and injection behavior. |
| T1059 — Command and Scripting Interpreter | Suspicious shell spawning in pipelines is a core execution-path detection target. | |
| Recommendation — Map abnormal process trees to T1055 and alert on injected or hijacked runner processes. Detect unexpected interpreter use in pipeline jobs and investigate spawned command chains. | ||
| NIST IR 8596 | Incident Detection and Analysis | Execution-layer evidence improves incident triage and confirmation. |
| Recommendation — Use process evidence to confirm compromise and scope runner activity during triage. | ||
Related resources from NHI Mgmt Group
- Why do indicator-based detections fail against modern identity attacks?
- How can teams reduce false positives in browser-based detections?
- How should security teams design flow-based detections that work across different telemetry sources?
- Why do LLM-based workflows increase privacy risk when they process raw business data and attachments?
