Runtime threat visibility in Splunk is the real CNAPP gap

At a glance

What this is: This is Aqua Security’s view of why runtime workload telemetry in Splunk matters, with the central finding that cloud native execution data is often stranded outside the SOC’s main investigation workflow.

Why it matters: IAM, PAM and NHI teams need this because workload-level signals, audit events and enforcement context increasingly determine whether identity-linked incidents can be investigated quickly and consistently.

Context

Runtime visibility is the gap between seeing that a workload exists and seeing what it actually did at execution time. In cloud native environments, that gap matters because blocked processes, policy violations and compliance failures can be the difference between a contained incident and a slow forensic scramble.

Aqua Security’s article argues that the operational problem is not a lack of security data, but a lack of shared investigation context. When runtime signals live in a separate tool from the SOC’s core telemetry, teams lose speed, continuity and evidentiary value exactly when they need all three.

Key questions

Q: How should security teams handle the gap between detection and investigation in Microsoft-heavy SOC environments?

A: Security teams should automate the investigative layer, not just the alerting layer. Sentinel and Defender can surface strong detections, but they do not remove the need to correlate identity, endpoint, email, and cloud evidence. The practical goal is to turn each alert into a completed, evidence-backed finding fast enough to support containment decisions before attackers expand their reach.

Q: Why do runtime events matter more than scan results during incident response?

A: Runtime events show what actually happened in a running workload, including blocked actions and policy enforcement, while scan results only describe state at a point in time. That makes runtime evidence more useful for determining impact, sequencing and containment when the incident is already under way.

Q: What breaks when workload telemetry is siloed from identity and network data?

A: Investigators lose the ability to correlate cause, effect and enforcement in one timeline. That slows triage, weakens forensic reconstruction and creates gaps when compliance evidence has to support the incident narrative. The practical failure is not missing logs, but missing shared context.

Q: How do teams judge whether runtime visibility is actually improving investigations?

A: They should measure whether analysts can resolve incidents without leaving the main SOC workflow, whether execution-time evidence is present alongside host and identity data, and whether audit findings can be traced back to concrete enforcement events. If those three conditions are not true, visibility is still fragmented.

How it works in practice

Why runtime telemetry becomes invisible to the SOC

Runtime telemetry is the event stream created when a container or workload starts processes, violates policy, or triggers enforcement at execution time. The issue is that many SOC workflows are centred on network, endpoint and identity data, while runtime events live in a separate control plane or security tool. That separation means the analyst sees symptoms in one place and the workload behaviour in another, which slows containment and weakens reconstruction. In cloud native environments, the missing layer is often not more data but the ability to correlate point-of-execution events with the rest of the incident timeline.

Practical implication: centralise runtime events alongside your main investigation dataset so analysts can correlate workload behaviour without tool switching.

How event forwarding changes enforcement context

Event forwarding through Splunk’s HTTP Event Collector is not just log shipping. It preserves the fact that a runtime alert came from an active control, such as a blocked process execution or a detected policy violation, rather than from a passive scanner. That distinction matters because enforcement-backed events carry stronger investigative value than scan noise or delayed summaries. Optional dashboards help, but the more important effect is that the SOC receives a record of what was prevented, not only what was observed. This turns runtime security into an investigation input rather than a separate product silo.

Practical implication: forward enforcement events, not just summaries, so investigators can distinguish active prevention from passive detection.

Why compliance and forensics depend on shared timelines

Compliance findings and forensic evidence both depend on consistent timelines. When runtime events, failed benchmarks and process lineage records are split across systems, auditors and investigators have to reconcile separate sources of truth. That creates avoidable gaps in chain-of-events analysis, especially when the question is what happened inside a container before, during and after a suspicious action. Bringing those records into Splunk makes the incident and the audit trail part of the same operational record, which is what most identity and security programmes actually need.

Practical implication: treat runtime findings as part of the evidentiary record, not a standalone console view, when building audit and forensic workflows.

NHI Mgmt Group analysis

Runtime visibility is now an identity governance problem, not just a logging problem: when workload execution signals sit outside the SOC’s primary dataset, teams lose the ability to relate behaviour to control decisions in one place. That breaks the practical value of audit evidence because the event, the enforcement action and the surrounding identity context no longer travel together. Practitioners should treat runtime telemetry placement as part of governance architecture, not a dashboard preference.

Point-of-execution signals change the value of cloud native security data: a blocked process or detected drift is materially different from a scan result because it shows behaviour at the moment it occurred. That is the kind of evidence SOC and compliance teams can use without waiting for a separate reconstruction step. The field should stop treating runtime controls as an isolated CNAPP function and start treating them as shared operational evidence for incident response, assurance and investigation.

Identity teams miss an important boundary when runtime data is siloed: the same host, container or workload often carries both identity-linked telemetry and execution-time enforcement signals, but only one of those is visible in many investigations. That creates a telemetry blind spot that is especially costly where workload identity, service accounts or delegated access are part of the attack path. The implication is that control ownership must extend beyond issuance and access rights into where runtime evidence is actually consumed.

Full visibility is a control outcome, not a tool outcome: the article’s real point is that SOC effectiveness depends on whether runtime events, audit logs and identity context can be analysed together. When they cannot, analysts spend time pivoting instead of deciding, and the programme loses both speed and evidentiary continuity. The governance question is therefore where the control data lands, not which console owns it.

Runtime threat visibility should be named as a distinct governance gap: the missing layer is not generic observability, but execution-time evidence that preserves enforcement context for cloud native workloads. That concept matters because it explains why some investigations feel complete in theory but incomplete in practice. Practitioners should recognise runtime threat visibility as a programme design issue that spans CNAPP, SIEM integration and identity-adjacent investigation workflows.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.
• Read next: Cloud Workload Identity Guide

What this signals

Runtime threat visibility is a governance boundary, not a logging preference: if execution-time evidence sits outside the SOC, the programme cannot reliably connect workload behaviour, identity context and enforcement outcomes. That is why runtime data placement now matters to NHI and cloud workload governance as much as to detection engineering.

5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs, which is a reminder that identity-related blind spots rarely stay confined to a single control domain. When runtime data is also fragmented, investigators inherit two visibility problems at once: who had access and what the workload did with it.

96% of security operations teams report critical blind spots, most commonly in cloud infrastructure and identity and access behaviour, according to the CNAPP-research article cited by NHI Mgmt Group: that is the operating context in which runtime telemetry must be joined to the SOC, not left in a separate console.

For practitioners

• Map runtime signals into the SOC dataset Route blocked processes, drift detections, policy violations and compliance findings into the primary investigation workflow so analysts do not pivot during incident triage.
• Preserve enforcement context in forwarded events Ensure forwarded events identify whether the signal was generated by active prevention, detection or audit so investigators can interpret severity and causality correctly.
• Correlate runtime events with identity telemetry Join workload execution records with host, network and identity signals for the same container or service account to reduce reconstruction gaps in forensics.
• Use runtime evidence in compliance reporting Include failed benchmarks, non-compliant images and enforcement-backed runtime findings in the audit record instead of treating them as separate operational data.

Key takeaways

• Runtime security data only becomes operationally useful when the SOC can analyse it alongside host, network and identity telemetry.
• The article’s core issue is not an absence of controls but a fragmentation of evidence at the moment investigators need a single timeline.
• Practitioners should treat runtime enforcement events as part of the incident record and the compliance record, not as a separate product feed.

Key terms

• Runtime telemetry: Observation of what a system actually does while it is executing. In agentic CI/CD, this means seeing which commands, files, tools, and credentials an agent touched so security teams can detect misuse that static workflow review will miss.
• Execution-Time Evidence: Execution-time evidence is the record of what a workload did at the moment a control intervened or a suspicious action was observed. In cloud native environments, it has higher investigative value than static findings because it preserves behaviour, not just configuration or posture.
• Enforcement context: Enforcement context is the control evidence attached to a security event, such as whether a process was blocked, a policy was violated, or a drift was detected. It tells investigators not only that something happened, but whether the platform actively intervened.
• SOC Investigation Workflow: A SOC investigation workflow is the sequence of tools, data sources and analyst actions used to triage alerts, confirm incidents and assemble evidence. When runtime events are excluded from that workflow, teams lose continuity and spend time reconciling separate views of the same workload.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.