Runtime security gaps in cloud-native environments are widening

At a glance

What this is: This is an analysis of why cloud-native runtime security is becoming a priority, with emphasis on the gap between static scanning and live application behaviour.

Why it matters: It matters because IAM, NHI, and platform teams all need controls that follow live execution, not just configuration state, when credentials, APIs, and workloads move faster than periodic review.

By the numbers:

• The report says Oligo grew 200% last year and is now the largest ADR vendor by revenue.

👉 Read Oligo Security's analysis of cloud-native runtime security and ADR

Context

Runtime security is the ability to see and control what applications and workloads are doing while they are live. Cloud-native environments make that harder because containers, Kubernetes, serverless functions, and multi-cloud services change too quickly for periodic scanning to capture real behaviour.

The governance gap is that many teams still treat posture data as if it were execution data. That works poorly when attackers move through IAM missteps, exposed APIs, and lateral movement inside running environments, because the control surface has already shifted by the time a scan completes.

For identity practitioners, the problem extends beyond application security into non-human identity governance. The same runtime blind spot that hides an exploit can also hide excessive workload access, over-permissioned service identities, and credentials being used in ways the provisioning model never anticipated.

Key questions

Q: How should security teams reduce cloud-native risk when static scanning misses live exploitation?

A: They should add runtime detection that confirms whether a weakness is actually executing, then use that signal to prioritise response. Static findings remain useful for inventory and hygiene, but they do not prove exploitability. The practical goal is to focus analysts on live attack paths, not theoretical exposure.

Q: Why do IAM missteps become more dangerous in cloud-native runtime environments?

A: Because identity abuse often becomes an execution problem once a token, role, or service credential is used inside a live workload. In cloud-native systems, access and runtime are tightly coupled, so a small entitlement error can translate into lateral movement or application compromise very quickly.

Q: What should teams measure to know whether runtime security is working?

A: They should measure whether detections identify active exploitability, not just whether assets are flagged as vulnerable. Useful signals include confirmed runtime execution, correlated identity misuse, and response actions that close the path before the attacker can move further.

Q: How do CDR and ADR change incident response in cloud-native environments?

A: They shorten the time between exploitation and containment by showing what is happening inside running applications and workloads. That gives SOC teams context on which process, credential, or service was involved, which is more actionable than a static alert after the fact.

Technical breakdown

Why static scanning misses runtime exploitability

Static scanners answer whether a file, container image, or policy contains a weakness. They do not answer whether that weakness is actually reachable, loaded, or executed in production. Runtime security closes that gap by observing live process behaviour, module loading, network activity, and exploit execution in the moment the application is running. That distinction matters in cloud-native systems because short-lived workloads can be created and destroyed faster than a periodic control cycle can inspect them. Without runtime telemetry, teams end up triaging theoretical exposure instead of real attack paths.

Practical implication: move from scan-only prioritisation to controls that confirm whether a weakness is executing in production.

How cloud-native attack paths cross IAM and runtime boundaries

The article points to IAM missteps, exposed APIs, and lateral movement inside Kubernetes as common intrusion paths. Those are not separate problems in practice. A weak identity posture can become an application-layer intrusion once a workload credential, token, or API trust relationship is abused inside a live environment. In cloud-native systems, the identity plane and runtime plane are tightly coupled, so a purely perimeter or configuration view misses the chain that connects access to execution. The practical question is whether security telemetry can correlate identity misuse with live workload behaviour.

Practical implication: correlate workload identity events with runtime detections so access abuse is visible as execution, not just entitlement drift.

Why cloud detection and response is replacing point-in-time posture alone

Cloud Detection & Response and Application Detection & Response are gaining traction because they focus on active attack progression rather than snapshot compliance. That includes correlating across applications, workloads, and cloud infrastructure, then feeding detections into existing workflows such as SIEM, SOAR, and DevOps tooling. This is not a replacement for posture management. It is a recognition that posture alone cannot show what an attacker is doing after initial access. The architecture shift is toward control loops that watch execution, validate exploitability, and preserve enough context for response.

Practical implication: treat runtime detections as a required control layer, then wire them into the SOC and engineering workflows you already operate.

Threat narrative

Attacker objective: The attacker wants to reach and manipulate live application execution while avoiding detection from controls that only understand static exposure.

1. Entry occurs through cloud-specific weaknesses such as IAM missteps, exposed APIs, or a vulnerable workload path that static tools did not validate as actively reachable.
2. Escalation happens when the attacker pivots inside Kubernetes or connected services, using runtime access to move beyond the original entry point.
3. Impact follows when the attacker reaches live application execution, where defenders without runtime visibility miss the critical parts of the attack chain.

Breaches seen in the wild

• Salt Typhoon US telecoms breach — Salt Typhoon APT used stolen credentials and Cisco CVE to breach US telecoms.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime visibility is now an identity problem, not only an application security problem. The article shows that attacks in cloud-native environments often begin with IAM missteps, exposed APIs, or workload access that becomes dangerous only when it is exercised live. That means the control question is not just whether an entitlement exists, but whether the entitlement is being used in a way that reflects actual runtime behaviour. The implication is that identity governance and runtime security can no longer be separated cleanly.

Short-lived workload identity creates a runtime gap that snapshot controls cannot close. Containers and serverless functions can appear and disappear before periodic scans or review cycles produce a usable signal. That is a structural problem for any control model built on delayed observation. Practitioners should treat this as an execution-time governance failure, not an alert-quality issue.

Identity blast radius is the right concept for cloud-native runtime risk. Once a workload credential or API trust relationship is abused, the damage depends on how far that identity can move inside live systems. The runtime layer exposes whether that blast radius is narrow, correlated, and containable, or whether it expands silently across workloads and services. Teams should measure the consequences of identity misuse by execution reach, not by entitlement count alone.

NIST Cybersecurity Framework 2.0 is more relevant when detection and response are tied to live execution. The article’s emphasis on runtime visibility maps most naturally to the detect and respond functions, but only if teams stop treating posture output as operational truth. That shift matters because cloud-native systems change too quickly for static inventory to remain authoritative for long. Practitioners should align controls to what is happening now, not what was true at scan time.

From our research:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to The 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, which is why runtime-aware governance is becoming a baseline requirement rather than a niche capability.
• For a broader identity control baseline, see NIST Cybersecurity Framework 2.0 and align detection and response to live execution instead of scan-only posture.

What this signals

Runtime is becoming the point where identity governance either proves itself or fails. As more cloud-native systems move from static infrastructure to short-lived execution, teams need controls that can see access being used, not just granted. The operational shift is toward correlating workload identity, API activity, and application behaviour in one response loop.

With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, the broader pattern is clear: identity programmes are still anchored to assumptions that live systems no longer respect. Runtime detection is therefore becoming part of identity assurance, not only an application security add-on.

Identity blast radius: the real question is how far a compromised workload, token, or API trust relationship can move before response can stop it. That pushes practitioners to prepare for execution-time containment, not just entitlement review, and to decide where runtime telemetry belongs in their IAM and SOC operating model.

For practitioners

• Prioritise runtime-confirmed exploitability Tune triage so vulnerabilities matter only when the function, container, or process is actually executing in production, then route those cases into response workflows immediately.
• Correlate IAM misuse with live workload behaviour Join identity telemetry, API access, and runtime detection so a compromised token or mis-scoped workload account is visible as an active attack path rather than a configuration issue.
• Map detection coverage across Kubernetes and serverless Verify that your monitoring can follow ephemeral pods, serverless functions, and short-lived jobs from start to finish, including the handoff into SIEM and SOAR.
• Use runtime context to shrink false-positive churn Suppress alerts that never execute in the live environment and preserve analyst time for activity that demonstrates real exploitability or post-compromise movement.

Key takeaways

• Cloud-native runtime security matters because static tools cannot reliably show whether an issue is actually being executed in production.
• The article frames IAM missteps, exposed APIs, and Kubernetes movement as live attack paths, which makes runtime visibility a governance issue as much as a detection issue.
• Practitioners should connect workload identity telemetry to runtime response so they can prioritise real exploitability and contain attacks before they spread.

Key terms

• Runtime Security: Runtime security is the practice of observing and controlling applications while they are actively running. It focuses on live behaviour such as process execution, network activity, and exploit attempts, which makes it different from static scanning or posture management that only evaluates state before execution.
• Application Detection and Response: Application Detection and Response is a security approach that identifies malicious activity inside running applications and helps teams respond before the attack spreads. It adds live visibility into execution context, which is especially useful when static tools can confirm a weakness but cannot show whether it is being exploited.
• Identity Blast Radius: Identity blast radius is the amount of damage a compromised identity can cause once it is used in a real environment. In cloud-native systems, the blast radius depends on how far a workload credential, token, or role can move across services before detection and containment interrupt the attack path.

What's in the full article

Oligo Security's full post covers the operational detail this post intentionally leaves for the source: the report framing, product-level positioning, and vendor-specific explanation of how its runtime approach fits into ADR.

• How the Frost & Sullivan report positions runtime detection across application, workload, and cloud infrastructure layers
• The vendor's detailed explanation of how it reduces noise by checking whether a vulnerable function actually loads and runs
• The implementation context for SIEM, SOAR, Jira, and DevOps integrations that this analysis only references at a high level
• The report-level claims about market growth and vendor positioning that practitioners may want for internal briefing material

👉 The full Oligo Security post covers the runtime detection framing, market context, and vendor-specific operational details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.