Why SOC Teams Need Runtime Visibility From Their CNAPP

Many companies run their software on cloud servers that come and go on their own. When traffic spikes, new ones switch on automatically. When it drops, they shut down, sometimes less than an hour after they started. That flexibility saves money, but it creates challenges for the people whose job is to investigate attacks.

Say an alert comes in that someone is secretly using one of those servers to mine cryptocurrency, on a machine that was switched on just 40 minutes earlier. The security analyst on shift has the obvious questions: how did the attacker get in, whose account are they using, and what else can that account reach? Before there’s time to find out, demand drops and the server shuts down.

The mining program is gone, and so are most of the clues inside the machine that could have explained what happened. The analyst may still have cloud logs, configuration data and an alert, but the process state, files and other artifacts that existed inside the workload have likely disappeared with it.

Cloud incident response has to account for this type of situation, because the infrastructure under investigation may exist for only minutes. Cybersecurity teams need to know what is actually running inside a workload, understand the surrounding cloud risk and respond while that workload still exists.

Runtime visibility from the CNAPP gives the SOC that window. Detections from the workload can arrive already connected to identity, exposure and data context. Evidence can be captured when the detection occurs, while an active malicious process can be stopped on the workload. Wiz, for example, follows this model by combining its agentless cloud view with the opt-in, agent-based Wiz Sensor on the same Security Graph. The result is that runtime activity can reach the SOC with the broader cloud context needed to understand what it means.

Google Cloud’s Cloud Threat Horizons Report H1 2026 shows how quickly attackers can move on new cloud systems. Throughout 2025, attackers who broke in through misconfigured applications had cryptominers and other payloads running on new cloud VMs and Kubernetes instances less than an hour after those instances came online. Defenders need near-instant detection and automated quarantine to keep up.

The same report found that software exploitation accounted for 44.5% of observed cloud initial access in the second half of 2025, up from 2.9% in the first half. Those attacks unfold inside live workloads. Processes start, payloads execute and network connections open. A scheduled posture scan or a ticket that enters an analyst queue later can provide useful information, but it cannot recreate every runtime event after the workload has disappeared.

What a CNAPP Without Runtime Signals Can’t Show the SOC

A CNAPP covers runtime threats only when it includes a runtime sensor on the workloads it protects. Posture scanning and cloud logs can show exposure and control-plane activity, but not what a process is doing inside a running container or VM.

Qualys TotalCloud, for example, pairs its scanning with eBPF-based runtime monitoring that can detect suspicious process behavior and trigger automated response playbooks.

The gap between scan data and runtime data shows up quickly during triage. An agentless scan can identify a vulnerable package on a workload. Runtime data can tell the analyst whether that package is actually loaded in memory. A container image can appear clean at deployment, while a running container later executes a program that was not part of the original image. Configuration data alone simply can’t reconstruct everything that process did.

Ephemeral infrastructure makes the gap more important. When a container terminates or a VM is recycled, volatile evidence can disappear with it. Waiting until an analyst manually starts collecting evidence may mean starting after some of the most useful artifacts are already gone.

For the SOC, this creates two common problems. Without runtime telemetry, analysts may spend time investigating posture findings that were never exploited. With runtime telemetry coming from a separate tool, they can face the opposite problem: a high-severity process alert with little immediate information about the workload’s identity, internet exposure, permissions or access to sensitive data.

Both slow down triage at the moment speed matters most, since within minutes an attacker can spread to other systems or the affected workload can shut down and take its evidence with it.

Why Agentless Context and a Runtime Sensor Belong on One Graph

Agentless CNAPP scanning and runtime protection answer different questions.

Agentless scanning connects through cloud APIs and workload snapshots to inventory resources, vulnerabilities, configurations, identities, network exposure and data risk without installing software on workloads. It is designed to build a broad map of the environment and identify where risk exists.

A runtime sensor runs with the workload and observes activity as it happens. On Linux, eBPF-based sensors can monitor processes, system calls, file activity and network connections at the kernel level. Windows requires a different approach, typically a lightweight kernel driver that passes events to software outside the kernel for analysis.

The SOC benefits when agentless scanning and runtime data are combined. Agentless scanning can show that an internet-facing VM contains a vulnerable library and has an identity capable of reaching sensitive storage. Runtime data can then establish that the affected library is actually loaded or that a suspicious process is actively using the workload.

The reverse is also important. A process alert by itself says relatively little about potential impact. Adding context from agentless scanning can show whether the workload is publicly exposed, runs with a privileged identity or sits on a path to sensitive data.

That’s why agentless and runtime capabilities are complementary. One establishes the environment and its possible attack paths. The other shows what is actually happening inside running workloads. Uptycs is built around that pairing, starting with agentless scanning and adding an eBPF sensor for runtime detection and response.

What Runtime Visibility in a CNAPP Should Give a SOC

For SOC teams evaluating CNAPP runtime visibility, the useful test is what an analyst receives when a detection fires.

Wiz offers a useful example of what that looks like in practice. Signals from Wiz Sensor are correlated with the Wiz Security Graph, allowing a runtime detection to be viewed alongside information such as workload identity, internet exposure and access to sensitive resources. Runtime validation can also identify vulnerable packages and libraries that are actually loaded in memory, giving analysts another way to distinguish an active risk from a vulnerability that merely exists on disk.

Investigation should also begin before an analyst has assembled the evidence manually. The Wiz Blue Agent, generally available since March 2026, can investigate detections using runtime, cloud and code context to help determine what happened and what may be affected. Wiz Forensics, which rolled out two months later, captures a forensics package when a workload detection occurs. That is particularly relevant for short-lived containers and other infrastructure that may no longer exist by the time a human analyst opens the case.

The third requirement is the ability to act on an active threat. In environments where Wiz Sensor is deployed, Runtime Response Policies can automatically terminate malicious processes on workloads, including VMs, containers and supported serverless environments. Teams can preview policies first, seeing exactly which processes they would terminate before switching them on. In containers, these policies can also block unapproved executables introduced after deployment.

This is where runtime visibility turns into response. The need for near-instant detection and automated quarantine is difficult to meet if every workload detection first has to leave the CNAPP, enter another queue and wait for a separate system to reconstruct the cloud context.

Coverage also has to reflect the SOC’s actual estate. Wiz Sensor runs on Linux and Windows VMs, Kubernetes and serverless containers, and extends runtime visibility into hybrid and on-premises infrastructure.

The operational question is therefore broader than whether a CNAPP generates runtime alerts. The SOC needs to know whether the alert arrives with enough context and preserved evidence to make a decision, and whether the platform can take an immediate containment action when the confidence level justifies it.

Where the SIEM and SOAR Fit

Runtime capabilities inside the CNAPP do not remove the need for the SOC’s existing SIEM and SOAR stack. They change the quality of what enters it.

Splunk is a common example of a SIEM. Wiz can send its issues, vulnerability information and audit logs into Splunk, where the SOC can correlate that cloud context with signals from endpoints, identities, networks and other enterprise systems. Connecting those dots remains important because a cloud workload may represent only one stage of a wider incident.

The difference is that the SIEM does not have to be the first place where an isolated workload event becomes understandable. Runtime evidence and cloud context can already be attached before the finding arrives. That supports the broader goal of cutting SOC noise without cutting visibility.

SOAR then handles the work that follows. Wiz findings can trigger Tines workflows that open tickets, notify resource owners or initiate follow-up remediation steps such as restricting access to an exposed storage bucket.

The sequence matters. Detection, cloud context and immediate workload containment can happen in the CNAPP. The SIEM correlates that incident with the rest of the enterprise. SOAR automates the downstream response process.

Runtime Visibility Belongs in the SOC’s Cloud Playbook

For SOC teams that need runtime visibility, the right CNAPP is one where a runtime detection arrives with evidence already captured and the potential blast radius already mapped, and where the analyst can contain the threat on the workload before it disappears.

That requires both sides of cloud security to work together. Agentless visibility establishes where risk exists across the environment. Runtime telemetry establishes what is happening now. Connecting the two lets analysts move from a suspicious process to the identity behind it, the assets around it and the data potentially at risk without reconstructing the environment from separate tools.

The next time a cloud server disappears halfway through an investigation, the node itself may be gone. The evidence and the answer should already be in the SOC’s hands.