Runtime vulnerability management reframes risk as a live decision

At a glance

What this is: This is an editorial argument for runtime vulnerability management, with the central finding that risk is determined by live exposure and exploitability rather than static severity scores.

Why it matters: IAM and security teams should care because the same governance problem appears across NHI, workload, and human access decisions: if you cannot verify what is actually active, you are managing volume instead of risk.

👉 Read Oligo Security's runtime vulnerability management analysis for the full decision model

Context

Runtime vulnerability management starts from a simple governance gap: most programs still treat findings as if they were equal, even when only some are reachable, exploited, or exposed in production. That creates a false sense of prioritisation, because severity in isolation is not the same as risk in your environment.

For identity security teams, the lesson extends beyond application vulnerability management. Whether the subject is human access, NHI credentials, or autonomous system permissions, controls fail when they are judged by inventory or ticket counts instead of validated exposure and live behaviour.

Key questions

Q: How should security teams prioritise vulnerabilities in runtime environments?

A: Prioritise by verified reachability, active invocation, and exposure, not by scanner volume or severity labels alone. A flaw that is present but unreachable is a different operational problem from one that is already active in production. The right question is whether the environment can prove the issue is contained, not whether the queue is empty.

Q: Why do static vulnerability scores often mislead executive decision-making?

A: Static scores describe the flaw, not the environment. They ignore compensating controls, production exposure, and attacker behaviour, which means they often overstate low-risk findings and understate reachable ones. Executives need a risk view that answers what is actually exposed and how quickly it can be contained.

Q: What breaks when compensating controls are not validated at runtime?

A: The organisation loses the ability to distinguish between a control that exists and a control that actually blocks attack behaviour. That gap creates false confidence, because the program may believe it has protection while the vulnerable path remains open. Validation turns a claim into evidence and should be mandatory for any serious prioritisation model.

Q: How can teams tell whether vulnerability management is reducing real risk?

A: Look for faster exposure confirmation, shorter exploit-to-containment intervals, and measurable blast-radius reduction across production systems. If the programme only shows ticket closure or scan coverage, it is tracking activity, not risk. Real progress appears when the organisation can prove that live threats are being constrained more quickly.

Technical breakdown

Why severity is not the same as runtime risk

Severity describes how bad a vulnerability could be in the abstract. Runtime risk depends on whether the vulnerable component is reachable, invoked, and exposed to an attacker in the actual environment. That distinction matters because a library can be present without being dangerous, while a called function in production can be a direct path to compromise. Runtime vulnerability management therefore shifts the unit of analysis from the CVE record to the live execution path. Practical implication: score findings by verified exposure and active reachability, not by static severity alone.

Practical implication: prioritise remediation based on live reachability and exploit behaviour, not on scanner output volume.

How exposure management converts unknowns into decisions

The article frames continuous monitoring as the mechanism that compresses uncertainty over time. That is the practical bridge between scanning and action: scanners create questions, but runtime evidence answers whether a control is actually blocking, whether an asset is internet-facing, and whether a compensating control really works. This is why exposure management is increasingly converging with vulnerability management. The real issue is not how many flaws exist, but which ones are observable, exploitable, and under validated control. Practical implication: build a validation loop that turns uncertain findings into confirmed exposure status.

Practical implication: establish a validation loop that proves whether compensating controls and exposure claims are real.

Why compensating controls need runtime proof

A compensating control is only meaningful if it blocks the exploit behaviour that matters. The article correctly points out that claims like edge filtering or WAF coverage are not enough without evidence from runtime behavior. This is a governance problem as much as a technical one, because teams often have the control, the diagram, or the policy, but not the proof that it constrained attack paths in production. In identity terms, the same principle applies to privileged access, service accounts, and ephemeral credentials. Practical implication: require evidence that the control blocked the real path, not just that it exists on paper.

Practical implication: require evidence that each control blocks the relevant attack path in production.

Threat narrative

Attacker objective: The attacker aims to turn a reachable runtime weakness into a production impact before the organisation can validate or contain it.

1. Entry occurs when a vulnerable component is reachable in production and exposed to attacker traffic.
2. Escalation happens when the vulnerable function is actually invoked, turning a latent flaw into an exploitable path.
3. Impact follows when the attacker can convert that reachable weakness into containment failure, service disruption, or broader compromise.

Breaches seen in the wild

• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

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 vulnerability management is really an exposure-verification discipline, not a finding-counting discipline. The article makes the right structural point: severity is only meaningful when joined to reachability, invocation, and compensating control evidence. That is why static queues keep security teams busy without materially reducing organisational risk. Practitioners should treat runtime validation as the primary decision layer.

Known unknowns are where most vulnerability programmes fail their governance test. The programme may know a CVE exists, but not whether it is reachable, compensatingly controlled, or exploitable in the actual environment. That uncertainty is not a tooling nuisance, it is a governance debt that keeps resurfacing in every prioritisation cycle. Practitioners should build processes that convert uncertainty into verified exposure status.

Compensating controls without evidence create the same blind spot as absent controls. A WAF rule, edge block, or policy statement does not reduce risk unless it demonstrably blocks the attack behaviour in production. This is the control-validation gap that separates mature runtime programmes from performative ones. Practitioners should measure proof, not presence.

Identity programmes should read this as a warning about control inventory without behaviour verification. The same failure pattern appears when human, NHI, or workload access is catalogued but never tested against live reachability or use paths. That means recertification, PAM, and lifecycle controls can drift into administrative theatre if they are not tied to runtime evidence. Practitioners should align governance reviews to live execution, not static entitlement lists.

Identity blast radius: the decisive unit of security is how far a real weakness can spread once it is active in production. That concept is visible here because the article moves the metric from ticket counts to containment and blast-radius reduction. Once that lens is adopted, the question changes from how many issues exist to how quickly the environment can confine one that matters. Practitioners should operationalise blast-radius reduction as a board-level risk metric.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For a deeper lifecycle lens, see NHI Lifecycle Management Guide for how visibility, rotation, and offboarding reduce hidden exposure.

What this signals

Runtime evidence will increasingly replace entitlement inventory as the basis for security decisions. The organisations that can prove reachability and containment will spend less time debating priorities and more time reducing exposure. That is especially relevant where control claims span human IAM, NHI access, and workload permissions, because static governance models collapse when they cannot see live behaviour.

One useful way to sharpen the programme is to treat compensating controls as verified assets, not assumed protections. That means aligning detection, validation, and containment around the same evidence path, then connecting it to broader operating models such as the NIST Cybersecurity Framework 2.0.

Identity blast radius: the next maturity step is not more findings, but faster confinement of the ones that matter. Teams that can connect runtime exposure to identity and access pathways will be better positioned to govern NHI, human access, and hybrid workloads with the same decision discipline.

For practitioners

• Measure verified exposure, not scanner volume Separate findings that are merely present from those that are reachable, invoked, and externally exposed in production. Build prioritisation rules that require evidence of exploitability before a ticket becomes an executive concern.
• Create a compensating controls register with proof requirements Record what each control blocks, where it operates, who owns it, and what runtime evidence proves it works. Revalidate the proof whenever the service path, deployment model, or attack surface changes.
• Track blast radius as a security KPI Use containment speed, reachable surface reduction, and exploit-to-containment time as the metrics that matter. That shifts leadership attention away from closed tickets and toward actual risk reduction.
• Convert unknowns into knowns through validation Treat every ambiguous finding as a request for proof, not a reason for debate. Ask engineering teams to show runtime call stacks, exposure checks, or blocking evidence before accepting a claim of mitigation.

Key takeaways

• Runtime vulnerability management changes the unit of work from counting findings to proving which weaknesses are reachable and exploitable in production.
• The strongest evidence in the article is that uncertainty, not raw CVSS severity, is what keeps vulnerability programmes from making decisive risk choices.
• Security teams should anchor prioritisation to validated exposure, control proof, and blast-radius reduction so that governance decisions reflect real operational risk.

Key terms

• Runtime Vulnerability Management: A vulnerability management approach that prioritises live exposure, reachability, and exploit behaviour instead of treating all scanner findings as equal. It uses runtime evidence to decide what matters now, then ties response to containment and validated control performance rather than static severity alone.
• Compensating Control: A control that reduces risk when the primary fix is not yet in place or is not enough by itself. In practice, it only counts if it demonstrably blocks the relevant attack behaviour in the real environment and can be verified with evidence, not just policy language.
• Blast Radius: The amount of damage an active weakness can cause before it is contained. In runtime security, blast radius is measured by how far an exploit can spread across systems, identities, or services, and how quickly the organisation can constrain that spread.

What's in the full article

Oligo Security's full general product post covers the operational detail this analysis intentionally leaves for the source:

• Runtime vulnerability management workflow details for separating exploitable findings from background noise
• The controls register structure the vendor uses to document compensating controls and validation evidence
• Practical examples of how runtime signals change prioritisation decisions in production environments
• The vendor's own explanation of how containment and blocking fit into the runtime operating model

👉 Oligo Security's full post expands on runtime prioritisation, compensating control evidence, and blast-radius reduction.

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 NHI governance in your organisation, it is worth exploring.