CISA’s vulnerability review shows why runtime security now matters

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Oligo Security's blog post: CISA's vulnerability review shows that exploitation continues to cluster around a small set of known weaknesses even as CVE volume accelerates sharply.

Why it matters: Security and identity teams need exploitability evidence, not just disclosure volume, because prioritisation based only on catalog data cannot keep pace with faster discovery and production exposure.

By the numbers:

• The Known Exploited Vulnerabilities Catalog grew from 1,185 entries to 1,422.
• CISA says 41.5 percent of everything in the KEV Catalog mapped to stubborn weaknesses across FY2024 and FY2025.
• VulnCheck found evidence of active exploitation for 884 vulnerabilities in 2025, while CISA added 245 to KEV.

Context

Vulnerability review now sits at the intersection of disclosure management, runtime security, and governance. The basic problem is that organisations still treat CVE volume as if it were a direct measure of risk, when the more operational question is whether a weakness is actually reachable and exploitable in production.

That matters for IAM and NHI programmes because the same logic applies to secrets, service accounts, and workload access paths. If a control only tells you that something is known, but not whether it is being exercised at runtime, it is not enough to prioritise remediation or prove blast-radius reduction.

CISA’s review makes that gap explicit by contrasting rapidly expanding disclosure volumes with a much smaller set of weaknesses that consistently drive compromise. The article frames runtime evidence as the practical answer, not because patching is obsolete, but because prioritisation now has to keep pace with attack automation.

Key questions

Q: What breaks when vulnerability prioritisation relies on exploitability scores alone?

A: Prioritisation breaks when scores are treated as confirmation rather than signals. AI can accelerate proof-of-concept generation, so a vulnerability may become actionable faster than a manual review can keep up. Teams then over-escalate noise, under-weight real exposure, and lose the ability to distinguish urgent fixes from theoretical ones.

Q: Why does runtime evidence matter more as AI speeds up vulnerability discovery?

A: AI makes new weaknesses appear faster than manual triage can absorb. Runtime evidence shows whether a flaw is being exercised in the actual environment, which is the only reliable way to distinguish urgent exposure from dormant risk when disclosure speed outpaces remediation capacity.

Q: How do teams know whether a vulnerability is actually dangerous in production?

A: They confirm whether the vulnerable code runs, whether the path is reachable, and whether the behaviour appears in live execution. Runtime context is the clearest indicator because it ties the flaw to real exposure rather than to catalogue status or theoretical severity. If the code is dormant, the operational priority should usually be lower.

Q: What should teams do when a weakness is not yet in KEV but appears exploitable?

A: Treat it as a live exposure problem. Contain the reachable path, add runtime monitoring around the affected function, and move the item ahead of lower-risk tickets even if it has not been formally confirmed in a vulnerability catalog.

Technical breakdown

Why CVE volume no longer tracks real exploitation

A CVE tells you that a weakness has been identified, not that it is being used against you. As disclosure volumes rise, especially when AI helps find more flaws faster, the signal-to-noise ratio gets worse. CISA’s review shows that exploited weaknesses cluster around a narrow set of recurring patterns rather than spreading evenly across the entire catalog. That means catalogue size is a poor proxy for operational risk. Security teams need to distinguish theoretical exposure from reachable exposure, because patch queues built only on volume will always lag attacker behaviour.

Practical implication: prioritise by exploitability evidence and exposure path, not by the raw number of open CVEs.

Why runtime security changes the prioritisation model

Runtime security works by observing what code and processes actually do in production, rather than inferring risk from static metadata. That matters because exploitability is often environment-specific: a vulnerable component may exist, but only some deployments expose the path an attacker needs. Runtime signals can show whether an application path is exercised, whether a suspicious payload reaches the vulnerable function, and whether behaviour matches a known exploit pattern. In governance terms, this turns patch management from a purely calendar-driven exercise into an evidence-driven control loop.

Practical implication: use runtime proof to decide which weaknesses deserve immediate remediation and which can wait behind stronger exposure controls.

How AI accelerates the gap between disclosure and defence

AI-assisted discovery increases the rate at which new weaknesses are found and disclosed, but it does not slow attacker adoption. That widens the window between first exposure and defensive recognition. CISA’s point is not just that more vulnerabilities are appearing, but that the pace of discovery makes traditional triage models less reliable. In practice, the defensive burden shifts from simply tracking known CVEs to detecting whether exploitation is happening before a ticket, a patch, or a KEV entry exists. That is a material change in operating model.

Practical implication: build detection and blocking controls that assume the next exploitable weakness may not yet have a CVE or KEV entry.

Threat narrative

Attacker objective: The attacker wants to exploit a reachable weakness in production before defenders have enough evidence or time to patch it.

1. Entry occurs when a known software weakness remains exposed in production and an attacker reaches it before remediation.
2. Credential access is not the main issue here; the attack path depends on application flaw exploitation such as SQL injection, command injection, or code injection.
3. Impact follows when the flaw is used to run arbitrary commands, reach unauthorized data, or execute malicious code inside the application environment.

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.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

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 evidence is becoming the decisive governance signal. CISA’s review shows why disclosure volume alone no longer tells practitioners what to fix first. When the catalog expands faster than remediation capacity, governance must shift from counting vulnerabilities to proving exploitability in production. For identity and access programmes, the same logic applies to secrets and service-account exposure. Practitioners should treat runtime proof as part of the control plane, not an after-the-fact detection layer.

AI-accelerated discovery creates vulnerability debt faster than patch programmes can absorb. The report’s baseline is important because it captures the moment before AI-driven discovery becomes even more common. That means the current gap between disclosed CVEs and actively exploited weaknesses is likely to widen before it narrows. The governance challenge is no longer whether teams can inventory known issues, but whether they can suppress exploitable paths quickly enough. Practitioners should re-rank remediation around exposure and behavioural evidence.

The article exposes a new named concept: exploitability latency. This is the time between a weakness becoming reachable in production and defenders being able to prove it matters. That latency is now the practical risk variable, because a vulnerability can exist long before it enters KEV or any prioritisation workflow. For identity security teams, exploitability latency also describes how long a leaked secret, overprivileged account, or reachable workload pathway can remain usable. Practitioners should reduce latency with runtime detection and blast-radius controls.

KEV should be treated as a floor, not a finish line. CISA’s own confirmed list is useful, but it is not a live census of all active exploitation. That distinction matters because many organisations use catalog inclusion as if it were equivalent to real-time threat presence. It is not. A mature programme needs both disclosure intelligence and production evidence. Practitioners should align patch urgency with runtime validation rather than waiting for formal catalog confirmation.

What this signals

Exploitability latency is now the control problem. Teams are no longer trying to manage only disclosure volume. They are trying to close the gap between when a weakness is reachable in production and when the security programme can prove that it matters.

Runtime context matters because vulnerable software and exploitable software are not the same thing. That distinction should shape patch priority, containment, and the way identity-adjacent services are monitored when they expose authentication, token, or workload pathways.

Organizations that keep treating vulnerability data as a static queue will continue to miss the cases that matter most. The better model is to use runtime behaviour to decide what gets fixed first and what must be contained immediately.

For practitioners

• Prioritise remediation by exploitability evidence Rank vulnerabilities by whether they are reachable, exercised, or already showing exploit-like behaviour in production, not by disclosure volume alone.
• Instrument runtime detection around high-risk weaknesses Monitor execution paths for injection, traversal, and authentication failures so teams can see when a flaw is actually being exercised.
• Use KEV as the minimum threshold for action Treat KEV inclusion as the floor for remediation urgency, then layer internal telemetry and asset context on top to find the exposures KEV does not capture.
• Tie vulnerability decisions to blast-radius reduction Where immediate patching is not realistic, restrict reachable attack paths, segment the affected service, and validate whether the vulnerable function can be invoked at runtime.

Key takeaways

• CISA’s review shows that the most dangerous vulnerabilities are not evenly distributed across the CVE catalog. They cluster around a small set of recurring weaknesses that keep reappearing in real compromises.
• The rapid growth in disclosed vulnerabilities makes catalogue-based prioritisation less reliable on its own. Runtime evidence is needed to tell whether a weakness is actually reachable and exploitable in the environment.
• For practitioners, the shift is operational rather than theoretical. Patch management must now be paired with behavioural monitoring and blast-radius reduction so teams can act before exploitation becomes impact.

Key terms

• Runtime Security: Runtime security is the practice of detecting and constraining malicious behavior while software is executing. It focuses on live workload activity, not just code quality or pre-deployment checks, so teams can contain abuse after a system is already running.
• Exploited vulnerability catalog: An exploited vulnerability catalog is a curated list of flaws known to be used in real attacks. It matters because active exploitation changes priority. In practice, it helps security teams separate theoretical risk from issues that require urgent remediation and tighter operational oversight.
• Exploitability context: Exploitability context is the evidence used to decide whether a vulnerability matters in a specific environment. It includes reachability, code path exposure, compensating controls, and product-specific advisories, and it turns raw scan data into a decision that can be defended.
• Runtime evidence: Cryptographic proof collected from the environment a workload is using, such as image hashes, cloud-signed metadata, boot measurements or code signatures. It is the material a verifier checks to decide whether an identity should be trusted.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical terms. It helps practitioners connect identity controls to wider security decisions across cloud, application, and production environments.