Runtime vulnerability management reframes risk as a live decision

At a glance

What this is: This is Oligo Security's argument that vulnerability management should be treated as a runtime decision problem, with live exposure and exploitability outweighing spreadsheet severity scores.

Why it matters: It matters because IAM, PAM, AppSec, and platform teams need to prioritise controls based on what is actually reachable and active, not on raw vulnerability counts.

Context

Runtime vulnerability management is the practice of judging vulnerability risk from what is happening in production, not from scanner output alone. That means exposure paths, active execution, compensating controls, and attacker behaviour become part of the decision, because a finding without runtime context does not tell you whether it is actually exploitable.

The article argues that most programs still behave like ticket factories, where severity and volume are confused with risk. For identity and security teams, the governance gap is the same one seen across NHI and workload identity work: you cannot manage what you have not verified in runtime.

The article's underlying point is that uncertainty is the real management problem. The article's starting position is typical of mature security conversations in 2026, but the operational message is sharper: move from counting findings to proving whether an issue can affect the live environment.

Key questions

Q: What breaks when application vulnerability teams rely on scanner output alone?

A: Teams end up with duplicate tickets, inconsistent severity labels, and no reliable way to separate theoretical flaws from exploitable risk. Scanner output is useful for discovery, but without correlation to reachability, asset value, and compensating controls, remediation becomes a queue-management problem instead of a security programme.

Q: Why do reachable vulnerabilities deserve higher priority than generic scan results?

A: Reachable vulnerabilities matter more because the application actually invokes the vulnerable function, which means the issue can move from abstract weakness to practical exposure. A scan result that never touches runtime code is noise until evidence proves otherwise. Security teams should spend remediation effort where execution paths make exploitation plausible.

Q: How do security teams know if compensating controls are actually working?

A: They should test whether segmentation, privilege reduction, and monitoring can stop movement before the vulnerable path reaches critical assets. A control is working when an assumed exploit can be contained without broad access, not when the patch finally lands. Tabletop exercises and red-team validation should prove that containment happens inside the exposure window.

Q: What should organisations do when exposure is uncertain but remediation is delayed?

A: They should use containment as the decision framework and reduce the blast radius while exposure is being confirmed. That may include isolation, blocking, or other compensating actions, but the priority is to constrain live behaviour before uncertainty turns into a production incident.

Technical breakdown

Why severity scores fail without runtime exposure

A CVSS score describes a vulnerability in isolation, while runtime risk depends on whether the vulnerable code is reachable, invoked, or protected by a compensating control. That distinction matters because libraries can exist in a build or image without ever being on an execution path. Runtime vulnerability management therefore treats observability as evidence, not opinion: if a vulnerable function is not called in production, its practical risk is lower than a higher-scoring issue that is actively reachable. This is the difference between inventory and exposure.

Practical implication: prioritise reachability and invocation evidence before assigning remediation urgency.

How uncertainty moves between known and unknown states

The Rumsfeld-style framing in the article works because it maps security work to decision quality. Known unknowns are questions you can name but have not validated, such as whether an internet-facing service is actually exposed. Unknown knowns are controls or mitigations that exist in practice but are not visible to the security program. Runtime monitoring reduces both by turning assumptions into observed facts, which is why the article treats continuous validation as the mechanism that compresses uncertainty over time.

Practical implication: build validation loops that convert assumptions about exposure and controls into verifiable runtime evidence.

Containment and blast radius as executive measures

Once risk is framed at runtime, the question shifts from how many vulnerabilities exist to how much damage a live exploit could cause before it is contained. That is why blast radius becomes the useful management lens: it captures how quickly behaviour can be constrained across a production environment. The article's emphasis on compensating controls, blocking by CWE type, and runtime evidence reflects a broader governance reality: reducing the scope of impact is often more actionable than waiting for perfect eradication.

Practical implication: measure how fast controls constrain live behaviour, not just how many tickets get closed.

Threat narrative

Attacker objective: The objective is to convert a latent software weakness into live production impact before the organisation can verify exposure or contain the behaviour.

1. Entry begins when a vulnerable component is present in production and becomes reachable enough for exploit behaviour to matter.
2. Escalation occurs when the weakness is confirmed as active in the runtime path, meaning the issue is no longer theoretical.
3. Impact follows when the program cannot contain the behaviour quickly enough and the blast radius expands before remediation catches up.

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.

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 vulnerability management is really about governance under uncertainty, not vulnerability counting. Scanner output produces inventory, but inventory is not risk. The decisive question is whether the issue is reachable, invoked, and capable of causing live impact in the environment where it runs. Practitioners should treat runtime evidence as the boundary between theoretical exposure and actionable risk.

Blast-radius reduction is the control objective that matters once a vulnerability is active. The article is right to move the executive conversation away from CVSS obsession and toward containment, because the most useful security metric is how quickly damage can be constrained. That is the more honest measure of operational resilience, especially when validation is still incomplete.

Runtime validation is becoming the missing trust layer between AppSec, platform teams, and security leadership. The article describes a familiar governance failure: one team says a mitigation exists, another says the finding is urgent, and neither can prove runtime reality. That gap is where modern vulnerability programmes lose credibility, so leaders should expect proof, not assertions.

Compensating controls become governance debt when they are not inventoried and validated. A mitigation that exists only in tribal knowledge or a slide deck does not change risk until the program can prove what it blocks and where it is enforced. The article's strongest contribution is its insistence that unverified controls are not controls in practice.

Runtime is now the correct operating plane for vulnerability decisions across software, cloud, and identity-dependent systems. The article's model fits a wider shift in security governance: the environment, not the scanner, is the source of truth. Practitioners should align prioritisation, response, and assurance to that reality before noise overwhelms decision-making.

What this signals

Runtime vulnerability management changes the operating model for security leaders. Programmes that still optimise for ticket closure are measuring work, not risk. The practical shift is to treat runtime evidence as the deciding factor for prioritisation, because only live exposure tells you whether a finding deserves executive attention.

Compensating controls register: a control is only real when the organisation can say what it blocks, where it applies, and how it was validated. That discipline matters because undocumented mitigations create false confidence, especially when engineering and security disagree about whether a risk is already covered.

For practitioners

• Prioritise reachable vulnerabilities first Rank issues by whether the vulnerable function is actually invoked in production, not by severity score alone. If runtime evidence cannot confirm exposure, treat the item as an open question rather than a finished risk decision.
• Measure blast-radius reduction Track how quickly compensating controls, isolation, or blocking mechanisms reduce the scope of impact once a weakness is identified. Use that measure to judge whether the programme is containing risk or simply creating more tickets.
• Create a compensating controls register Record what each control exists to block, where it is enforced, how it was validated, and who owns it. Treat unvalidated claims as governance debt until the runtime evidence is available.
• Convert incident lessons into policy Feed runtime findings back into detections, blocking rules, and repeatable guardrails so the same weakness does not reappear as a new priority item. The goal is to turn one-off discovery into durable control.

Key takeaways

• Runtime vulnerability management exposes the difference between vulnerable code and vulnerable behaviour in production.
• The article's central evidence is that blast radius and containment are better executive measures than scanner counts or raw CVSS.
• Teams should replace assumption-based prioritisation with runtime validation, compensating-control evidence, and containment metrics.

Key terms

• Runtime Vulnerability Management: Runtime Vulnerability Management prioritises flaws based on what software actually does in production, not only on static scan results or catalogue entries. It combines execution telemetry, reachability, and exploit signals to determine whether a finding is genuinely actionable in the current environment.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.
• 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.

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.