Runtime truth for cloud-native security: why scanners still miss risk

At a glance

What this is: This is an Oligo Security analysis arguing that cloud-native scanners miss active risk because they reason from build-time theory instead of runtime execution.

Why it matters: For IAM and NHI practitioners, the core issue is that access, dependency, and workload behavior must be evaluated where code runs, not only where artifacts are scanned.

By the numbers:

• Oligo Security says it can reduce vulnerability backlogs by 90% to 99% within 48 hours.
• Oligo Security says its runtime blocking keeps CPU overhead below 0.5%.

👉 Read Oligo Security's analysis of runtime truth for cloud-native security

Context

Cloud-native security often overstates coverage because it treats scanned configurations and code as proof of safety. The real gap is runtime, where business logic executes, secrets are used, and third-party dependencies can become attack paths. For IAM and NHI programs, that means entitlement decisions made only at build time can miss the privileges and execution paths that matter in production.

The article frames Deep Application Inspection as a way to observe library and function execution in production so teams can separate theoretical findings from reachable risk. That matters because non-human identities, service workloads, and AI-driven components all inherit the same blind spot when security tools cannot see what actually runs. In practice, this is typical of mature cloud environments that have invested in scanning but not in execution-aware governance.

Key questions

Q: How should security teams prioritize vulnerabilities in cloud-native applications?

A: Prioritize vulnerabilities by whether they are reachable and exploitable in production, not by scanner volume alone. Build-time findings are useful for inventory, but runtime evidence shows what attackers can actually trigger. That approach reduces false positives, focuses remediation on live code paths, and gives security teams a defensible basis for escalation decisions.

Q: Why do static scanners miss some cloud-native attack paths?

A: Static scanners evaluate code, manifests, and configurations before execution, so they cannot reliably see dynamic loading, runtime state, or conditional code paths. In cloud-native systems, that creates blind spots around actual behavior. The practical answer is to add execution-aware inspection so teams can separate theoretical weaknesses from reachable threats.

Q: What is the difference between theoretical vulnerability and reachable risk?

A: A theoretical vulnerability exists in code or configuration, but reachable risk exists when the vulnerable path is active in production and can be exercised by an attacker. The distinction matters because remediation capacity is limited. Security teams should treat reachability as the threshold for urgent response and exploitability as the basis for prioritization.

Q: How can organisations reduce alert fatigue from cloud security tools?

A: Reduce alert fatigue by filtering findings through runtime evidence, business context, and actual execution paths. When teams know which functions run in production, they can suppress low-value noise and focus on issues that affect live services. That improves response speed and makes remediation queues more credible to engineering teams.

Technical breakdown

Why build-time analysis misses reachable cloud-native risk

Build-time analysis inspects code, manifests, and dependencies before the application is running. That is useful for inventory and hygiene, but it cannot prove whether a vulnerable function is reachable in production, whether a dependency is dynamically loaded, or whether an attacker can trigger the code path under real runtime conditions. In cloud-native systems, the gap is wider because orchestration, containers, and AI-assisted behavior can change execution patterns after deployment. The result is a large set of possible weaknesses and a much smaller set of exploitable ones. Security teams need to distinguish between exposure and exploitability if they want to reduce noise without missing active threats.

Practical implication: Prioritize controls that validate reachability in production, not just scanner output.

How runtime inspection changes vulnerability prioritization

Runtime inspection observes actual application behavior while the workload is live. At the library and function level, it can show which code paths execute, which dependencies are present in memory, and which parts of the codebase are genuinely active. That shifts prioritization from theoretical severity to verified exploitability. In practice, this is a better fit for modern cloud-native estates because it aligns remediation with what attackers can actually touch. It also reduces the false-positive burden that slows down AppSec, cloud security, and platform teams. The key architectural point is simple: if security cannot observe execution, it cannot reliably rank risk.

Practical implication: Use execution evidence to decide which findings enter the remediation queue.

Why runtime exploit blocking matters for live attack paths

Runtime exploit blocking sits at the point where malicious input meets executing code. Instead of waiting for a patch cycle, the control interrupts specific function calls or dangerous behavior as it happens. That is especially important for zero-day exposure, where signature-based or configuration-based tools may have no immediate answer. The tradeoff is performance, so the control has to work with minimal overhead and without breaking application availability. In cloud-native environments, that makes runtime enforcement a governance issue as much as a detection issue, because it protects the service while preserving operational continuity.

Practical implication: Plan to block high-risk execution paths while keeping service uptime intact.

Threat narrative

Attacker objective: The attacker wants to turn a theoretically known weakness into an actively exploitable runtime path that produces access, disruption, or reach into adjacent systems.

1. Entry occurs when attackers target a reachable runtime path that static scanners did not prove safe in production.
2. Escalation follows when malicious input or abused functionality reaches a live library or function with meaningful execution authority.
3. Impact comes from runtime misuse, including data exfiltration, service disruption, or lateral movement through the workload's permissions.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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 truth is now a governance requirement, not an optimization. Static scanners and posture tools still matter, but they cannot settle the core question of whether a workload can actually be exploited in production. That gap becomes more serious as applications absorb AI behavior, dynamic dependencies, and non-human identities with execution authority. Practitioners should treat runtime visibility as the control that converts theory into evidence.

Reachability is the missing decision layer in cloud-native security. A long vulnerability list is not the same thing as an exposure list, and an exposure list is not the same thing as an exploitability list. DAI-style inspection narrows the field to code paths that are live, which is what remediation teams need when budgets and staff are finite. The practical conclusion is to stop measuring success by scan volume and start measuring verified risk reduction.

Identity and execution are converging in the workload layer. Workloads, service accounts, and AI agents all inherit risk when security teams cannot see what executes and what authority that execution carries. That makes runtime protection part of NHI governance, because non-human identities are only as safe as the code paths they can trigger. Teams should align workload identity controls with execution-aware monitoring.

Runtime exploit blocking changes the security objective from detection to interruption. A control that can neutralize malicious behavior in real time narrows the window between exploit and impact. That does not replace patching, but it does change how teams should think about zero-day exposure and production resilience. The field should expect more security programs to move from alert-centric models to execution-centric enforcement.

Named concept: runtime truth. This article sharpens a useful concept for the market: runtime truth is the evidence that comes from observing what code actually does in production, not what a scanner predicts might happen. It is a better basis for prioritization, and in cloud-native estates it should be the standard for high-confidence remediation decisions. Practitioners should adopt it as the threshold for action, not as an optional enhancement.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, even though 92% agree that governing AI agents is critical to enterprise security.
• For a broader control baseline, see OWASP NHI Top 10 for the most relevant agentic application risk patterns.

What this signals

Runtime truth is becoming the practical boundary between acceptable noise and actionable risk. As cloud-native estates accumulate more dynamic dependencies and autonomous components, teams will need evidence from execution, not just from scanners, to decide what merits remediation. That shift will also improve how NHI and workload identity programs decide where privilege actually matters.

With 70% of organisations already granting AI systems more access than human employees, per the 2026 Infrastructure Identity Survey, runtime-aware governance becomes the only credible way to verify whether those permissions are being exercised safely. Static approval records are not enough when the workload itself can change behavior after deployment. Practitioners should expect runtime monitoring to become part of access review, not a separate security niche.

The operational next step is to align cloud security, AppSec, and identity teams around a shared view of reachability. When policy, telemetry, and execution context are joined together, organisations can cut backlog without lowering assurance. For deeper context on identity risk patterns, compare this analysis with The 52 NHI breaches Report.

For practitioners

• Map findings to reachable code paths Require production evidence before moving a vulnerability into urgent remediation. Separate issues that exist in artifacts from issues that can be executed in the live environment, and document which services, libraries, and functions are actually reachable.
• Prioritize exploitability over raw scanner volume Tune queues and SLAs around verified runtime risk, not the total number of findings. That helps teams spend time on code paths that can be touched by attackers instead of spending cycles on theoretical noise.
• Protect high-risk execution points in production Place blocking controls where malicious input would reach live functions, especially in workloads that process secrets, customer data, or automated actions. Keep the control scoped so production availability is preserved.
• Review workload identity assumptions with runtime context Check whether service accounts and other non-human identities have more execution reach than their intended role requires. Pair least privilege with runtime observation so identity policy reflects real behavior.

Key takeaways

• Cloud-native security fails when it treats build-time findings as proof of real-world exposure.
• Runtime visibility changes remediation from theoretical triage to verified exploitability decisions.
• For NHI and IAM teams, execution-aware controls are becoming part of governance, not just detection.

Key terms

• Runtime truth: Runtime truth is the evidence produced by observing what software actually does in production. It replaces guesswork with execution data, allowing security teams to judge whether a vulnerability is reachable, whether a dependency is active, and whether a control needs to block behavior now rather than later.
• Deep Application Inspection: Deep Application Inspection is an execution-aware inspection approach that observes application behavior at the library and function level. It helps teams identify which code paths run in production, so prioritization can focus on verifiable risk rather than on static assumptions that may never materialize.
• Reachable risk: Reachable risk is a weakness that can be exercised in a live environment, not just detected in source code or configuration files. It is the practical threshold that separates low-value noise from issues that can lead to exploitation, data exposure, or service disruption.
• Runtime exploit blocking: Runtime exploit blocking is a control that interrupts malicious behavior while code is executing. It is different from detection alone because it acts at the point of exploitation, helping reduce the time between attacker input and impact without depending on a patch cycle or manual response.

Deepen your knowledge

Runtime visibility and workload identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to close the gap between scanner findings and production reality, it is worth exploring.

This post draws on content published by Oligo Security: Cloud Native Security Failures: Why Attackers Still Win. Read the original.