Notifications
Clear all
Topic starter
15/05/2026 7:52 pm
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.
NHIMG editorial — based on content published by Oligo Security: Cloud Native Security Failures: Why Attackers Still Win
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%.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map findings to reachable code paths Require production evidence before moving a vulnerability into urgent remediation.
- Prioritize exploitability over raw scanner volume Tune queues and SLAs around verified runtime risk, not the total number of findings.
- 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.
That shift will also improve how NHI and workload identity programs decide where privilege actually matters?
👉 Read Oligo Security's analysis of runtime truth for cloud-native security →
Explore further
15/05/2026 7:53 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Runtime truth for cloud-native security: why scanners still miss risk
