TL;DR: Static scanners and build-time analysis can flag large volumes of theoretical issues, but they do not show what code actually executes in production, according to Oligo Security. Runtime inspection shifts the question from potential exposure to verifiable risk, making exploitability and live blocking the decisive controls.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Oligo Security's blog post: Build-time scanning misses production reality, while runtime inspection changes vulnerability prioritisation.
Why it matters: For IAM, NHI, and cloud security practitioners, it matters because access, exploitability, and control effectiveness have to be judged against what actually runs, not what static tools infer.
Context
Cloud-native security tools often overstate coverage when they evaluate code, infrastructure, or configuration before anything is exercised in production. The core governance gap is simple: build-time findings do not tell teams which paths are actually reachable, which dependencies are loaded, or which weaknesses can be exploited in a live runtime.
That matters for identity and access programmes because runtime execution is where privileges, tokens, service accounts, and workflow permissions are actually used. If security teams cannot see execution behaviour, they cannot reliably separate theoretical exposure from active risk, and remediation effort drifts toward what is easy to measure rather than what is dangerous.
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: What breaks when security tools cannot see runtime execution?
A: When runtime execution is invisible, teams lose the ability to separate theoretical exposure from active risk. Static findings may be accurate, but they do not show whether code paths are invoked, whether dependencies load dynamically, or whether a weakness can be exploited in production. The result is misplaced remediation effort and missed attack paths.
Q: How do teams know if a vulnerability is truly exploitable?
A: They validate it in the live environment using safe testing that shows whether an attacker can reach the condition, trigger it, and move beyond it. Scanner data alone cannot answer that question reliably. Validation gives defenders evidence they can use to separate theoretical issues from immediate response priorities.
Q: What should teams do when runtime protection can only observe suspicious activity?
A: They should use observation for tuning, but move high-confidence malicious patterns into enforcement. If a threat family is built to survive and hide, passive visibility can arrive too late. The goal is to stop execution before the malware finishes setting up persistence and concealment.
Technical breakdown
Why build-time scanning misses runtime risk
Static scanners reason from source, manifests, or images. They can identify vulnerable packages, misconfigurations, and known patterns, but they cannot prove whether a function, library path, or dependency is invoked in production. In cloud-native systems, dynamic imports, feature flags, container layering, and ephemeral execution all reduce the value of pre-execution inspection. The result is a high-volume list of potential issues with weak signal on exploitability. For identity and access teams, that means risk cannot be inferred from presence alone. A vulnerable component that never runs is not the same as a reachable attack path in production.
Practical implication: Prioritise controls that prove runtime reachability before assigning remediation effort.
What runtime truth changes in cloud-native security
Runtime truth means observing code execution as it happens, including the library and function level. That approach separates theoretical exposure from verifiable risk by showing which code paths are live, which third-party dependencies are active, and where sensitive business logic is actually processing data. This is especially relevant in environments where AI-driven behaviour, dynamic dependency loading, and multi-service execution make static reasoning brittle. Runtime visibility also supports exploit blocking, because controls can target the exact malicious function or execution path instead of the entire application.
Practical implication: Use runtime inspection to anchor vulnerability management in observed execution rather than inferred exposure.
Why exploitability matters more than raw vulnerability volume
Large vulnerability backlogs often reflect tool output, not operational danger. If a platform cannot distinguish reachable from unreachable issues, teams waste time on low-value remediation and miss the smaller set of weaknesses that are actually exploitable. This is a governance problem as much as a technical one, because prioritisation determines whether the security programme protects the business or merely records defects. Runtime protection shifts the emphasis from counting findings to proving impact, which is the only defensible basis for urgent action in production systems.
Practical implication: Rank remediation by exploitability, not by scanner output volume.
Threat narrative
Attacker objective: The objective is to turn reachable runtime behaviour into practical compromise, then use that foothold to steal data, disrupt services, or expand access.
- Entry often occurs through exploitation of a reachable runtime weakness rather than a flaw that only exists in build-time analysis.
- Credentialed or trusted functionality can then be abused inside the runtime, including legitimate APIs, dynamic dependencies, or business logic paths.
- The attacker escalates by chaining accessible code paths and moving laterally through permissions already present in the application environment.
- Impact follows through data access, service disruption, or broader compromise that static scanners did not identify as active risk.
Breaches seen in the wild
- Commvault Metallic breach 2025: A nation-state actor exploited a Commvault zero-day in Azure and may have taken app secrets that open customers' Microsoft 365 tenants.
- United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Runtime truth is now a governance requirement, not a visibility enhancement. Static tools answer what might be wrong, but production teams need to know what is actually reachable, executable, and exploitable. That shifts the security programme from theoretical coverage to evidence-based prioritisation, which is the only defensible way to allocate remediation effort in cloud-native environments. The practitioner conclusion is that risk ownership belongs to runtime evidence, not scanner volume.
Build-time theory creates trust debt in cloud-native programmes. Teams that rely on pre-execution analysis accumulate unresolved assumptions about what code paths matter, which dependencies execute, and which alerts deserve attention. That debt compounds when dynamic loading, AI-driven behaviour, and ephemeral execution make static inference less reliable. The practitioner conclusion is to treat reachability as the control boundary, because untested assumptions are where prioritisation breaks down.
Runtime exploit blocking changes the meaning of control effectiveness. A control is only useful if it can intervene at the point where malicious behaviour becomes operationally real. That makes runtime enforcement, not just detection, the decisive differentiator for modern cloud-native defence. The practitioner conclusion is that teams should judge security by whether harmful execution can be stopped in production, not by how many findings were generated upstream.
Deep Application Inspection exposes the identity of active risk. The important question is no longer whether a vulnerability exists in a repository, but which live code paths, libraries, and services are actually carrying business-critical exposure. That matters for NHI governance because service permissions, runtime credentials, and application reachability converge at execution time. The practitioner conclusion is to align vulnerability management with observed identity-bearing execution paths.
Cloud-native security teams need a reachable-risk model. A mature programme distinguishes between latent defects and exploitable conditions, then uses that distinction to drive response, reporting, and executive prioritisation. Without that model, teams will continue to mistake data exhaust for operational insight. The practitioner conclusion is that scanners remain useful inputs, but runtime truth must decide what gets fixed first.
From our research library:
- Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.
What this signals
Runtime truth is the missing layer in cloud-native governance. Programmes built around code scanning and configuration review need a live-execution check before they can claim they understand exposure. That is especially important where service identities, dynamic dependencies, and production logic intersect at runtime.
Static visibility remains useful for hygiene, but it cannot tell teams which findings matter in production. The practical signal for practitioners is to move prioritisation toward reachable risk, then use runtime enforcement to shrink the set of issues that ever reach an incident review.
Reachability is now the deciding control boundary. When execution can be observed directly, security teams can stop treating every scanner finding as equally urgent. That changes backlog management, incident response, and board reporting because the programme can finally distinguish noise from exploitable conditions.
For practitioners
- Prioritise reachable vulnerabilities Score findings by whether the affected function or dependency executes in production, then defer issues that lack runtime evidence until they become reachable.
- Instrument production execution paths Monitor library and function-level activity in live workloads so remediation decisions reflect actual code paths rather than image, manifest, or repo state.
- Use runtime exploit blocking Block malicious behaviour at execution time where the application is processing live requests, tokens, or data instead of waiting for patch cycles.
- Reduce scanner-driven alert fatigue Collapse duplicate or low-signal findings into a smaller set of verified, exploitable issues so the team can focus on response that changes exposure.
Key takeaways
- Static cloud-native scanning is not enough when production execution determines whether a weakness matters.
- Runtime visibility changes vulnerability management from theoretical exposure to verified, reachable risk.
- The right control objective is to stop or prioritise what can actually execute, not what simply exists in a repository.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Runtime compromise can expose secrets and tokens that static scanners do not see in use. |
| NHI-05 — Overprivileged NHI | Runtime abuse becomes worse when application identities can move laterally with excess privilege. | |
| Recommendation — Scan live workloads for leaked secrets and revoke any credential exposed through active execution paths. Reduce NHI privilege scope so a runtime compromise cannot expand into broader infrastructure access. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article's attack pattern centres on runtime exploitation leading to credential use and wider compromise. |
| Recommendation — Map runtime exploitation paths to credential access and lateral movement techniques in detection and response. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article argues that effective control depends on what is actually authorised and reachable in production. |
| Recommendation — Validate production entitlements against observed execution so authorisation reflects real runtime risk. | ||
| CIS Controls v8 | CIS-5 — Account Management | Service and application accounts become dangerous when runtime access is not governed against live use. |
| Recommendation — Audit account usage in production and remove any application account that no longer has a justified runtime purpose. | ||
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.
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
- 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.
- 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
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.
Published by the NHIMG editorial team on May 15, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org