CISA’s vulnerability review shows why runtime security now matters

At a glance

What this is: This is an analysis of CISA’s FY2024-2025 vulnerability review, showing that exploited flaws cluster around a small set of repeat weaknesses while new CVEs are growing much faster than confirmed exploitation.

Why it matters: It matters because security and identity teams need a defensible way to prioritise exposure, especially where runtime controls, authentication boundaries, and access checks determine whether a weakness can actually be abused.

By the numbers:

• Across FY2024 and FY2025, 41.5 percent of everything in the KEV Catalog mapped to stubborn weaknesses that have appeared on MITRE’s most-dangerous list every year since at least 2019.
• VulnCheck found evidence of active exploitation for 884 vulnerabilities in 2025, while CISA’s KEV Catalog added 245 that same year.
• VulnCheck had evidence of exploitation before CISA added the matching CVE to KEV more than 85 percent of the time in 2025.

👉 Read Oligo Security’s analysis of CISA’s FY2024-2025 vulnerability review

Context

CVE volume is not the same thing as exploit volume. When disclosure accelerates faster than remediation, the real governance problem becomes prioritisation: deciding which weaknesses are actually exploitable in production, which are merely theoretical, and which can be blocked at runtime before a patch lands. For IAM and security teams, that distinction matters because missing authentication, code injection, and command injection often become access-control failures before they become classic application bugs.

Oligo Security uses CISA’s FY2024-2025 review to argue that the industry is still over-indexing on catalog counts while attackers continue to focus on a small set of repeatable weaknesses. The identity angle is direct: when a critical function is reachable without authentication, or when malicious code can execute inside an application path, the control failure is not just vulnerability management but also entitlement, trust boundary, and runtime enforcement failure.

That starting position is typical of modern enterprise environments, where exposure is widespread and signal quality is poor.

Key questions

Q: What breaks when known vulnerabilities are not validated at runtime?

A: Teams lose the ability to distinguish theoretical exposure from exploitable exposure. That leads to noisy patch queues, delayed containment, and missed active abuse paths. Runtime validation shows whether the vulnerable code path is actually executed, which is the only reliable way to confirm whether a flaw can affect production systems before remediation is complete.

Q: Why do repeat CWE classes keep causing breaches even when teams know about them?

A: Because the failure is usually operational, not informational. Organisations may recognise SQL injection or missing authentication, but they still leave exposed code paths, weak input handling, or incomplete access checks in production. Known weakness classes keep recurring when governance, code review, and runtime enforcement are not connected.

Q: How do security teams know if CVE prioritisation is actually working?

A: CVE prioritisation is working when teams can consistently separate theoretical exposure from actionable risk. Useful signals include shorter triage cycles, fewer false positives, remediation based on exploitability rather than score alone, and better alignment between scanner findings and real application context. If teams still chase every CVE equally, the process is not effective.

Q: Who should own remediation when compliance software finds overprivileged access?

A: The entitlement owner, not the compliance tool, should own the decision and the follow-through. Compliance platforms can flag issues and track status, but they cannot replace business accountability for reducing access or removing it entirely.

Technical breakdown

Why CVE growth is outpacing exploitable risk

CVE volume is a disclosure measure, not a compromise measure. CISA’s review shows that the catalog can double while confirmed exploitation grows far more slowly, which means organisations must separate published weakness from operational exposure. The practical issue is that AI-assisted discovery can produce more findings without changing the underlying pattern of abuse. Security teams therefore need triage logic that looks at exploitability in context, not just severity scores or publication counts.

Practical implication: rank vulnerabilities by exploit path, exposed asset, and runtime reachability, not by CVE volume alone.

Why the same weakness classes keep reappearing

CISA names SQL injection, improper input validation, path traversal, command injection, code injection, and missing authentication for critical function as the core drivers of real-world compromise. These are not novel techniques. They persist because they reflect durable control failures in input handling, request validation, and access checks. The fact that 41.5 percent of KEV entries map to stubborn weaknesses shows that attackers repeatedly exploit classes of flaws that defenders already understand well.

Practical implication: treat repeat CWE classes as governance problems and enforce secure code review and runtime compensating controls around them.

Why runtime security becomes the decision layer

Runtime security matters because it answers the question static scanning cannot: is the vulnerable path actually executed in your environment, and can malicious behaviour be blocked without breaking production? That is especially relevant where missing authentication or command injection creates immediate misuse potential. In identity terms, runtime controls help prove whether a function is reachable without the expected trust check, which is the difference between latent weakness and active exposure.

Practical implication: pair runtime enforcement with vulnerability management so exposure is validated before remediation tickets are closed.

Threat narrative

Attacker objective: The attacker’s objective is to turn a known software weakness into direct execution, access, or data exposure before defenders can patch or detect it.

1. Entry occurs when attackers target a known weakness such as SQL injection, command injection, path traversal, or missing authentication for a critical function.
2. Escalation follows when the flaw lets the attacker run code, reach protected files, or invoke privileged application functions without the intended trust check.
3. Impact is achieved through data theft, system compromise, or downstream execution that turns a single software weakness into broader operational exposure.

NHI Mgmt Group analysis

Runtime exploitability is becoming the real control boundary. CISA’s review reinforces that catalog size is not the same as business risk. What matters is whether a weakness is actually reachable, executable, and exploitable in production. For identity and access teams, that means runtime evidence increasingly determines whether a control gap is real or theoretical. The practitioner conclusion is simple: vulnerability management now depends on enforcement, not just inventory.

Missing authentication for critical function is an identity failure, not only an AppSec defect. When a sensitive function is exposed without an auth check, the issue sits squarely at the boundary between application security and IAM governance. That is why access-control validation, trust boundary review, and runtime policy enforcement all matter together. This is where NIST SP 800-53 and Zero Trust thinking intersect with application risk, and practitioners should treat these flaws as governance breakdowns, not isolated bugs.

Stubborn weaknesses create governance debt that AI will expose faster. CISA’s note that AI-enabled discovery is increasing disclosure volume means the same old flaw classes will surface more often, not less. That creates pressure to move from reactive patch queues to exposure-based prioritisation. Runtime exposure visibility becomes the named concept here: if you cannot tell which weaknesses are executable in your environment, you cannot govern remediation intelligently. The practitioner conclusion is to measure exploitability, not just count findings.

KEV is a floor, not a ceiling, for defensive action. CISA’s confirmed exploitation list is useful, but it will always lag the full attack surface. The gap between independent exploitation intelligence and KEV inclusion shows why defenders need broader telemetry and faster blocking mechanisms. For identity-linked systems, that means validating trust checks, session boundaries, and privileged function access continuously. The practitioner conclusion is to use KEV as a minimum bar and runtime controls as the deciding layer.

Policy models must account for the next instance of the same weakness class. The report’s clustering around six recurring CWEs means the next exploit may not appear on a list before it is abused. That is a governance challenge for security programmes that still tie action to published identifiers. The better model is to maintain controls around weakness classes, not just named CVEs. Practitioners should therefore organise remediation and runtime detection by pattern, not by vendor or patch cycle.

What this signals

Runtime exposure visibility: the practical next step for many programmes is to connect vulnerability triage, application telemetry, and identity control checks so teams can see whether a flaw is actually executable in production. That reduces dependence on static lists and makes remediation decisions more defensible.

For identity-heavy applications, the key question is no longer whether a weakness exists, but whether the trust boundary still holds when code runs. That is why runtime controls, access validation, and exposure-based prioritisation should now sit alongside patch management and secure coding. See also NIST SP 800-53 Rev 5 Security and Privacy Controls and Ultimate Guide to NHIs , Key Challenges and Risks.

Teams that still treat KEV as the end of the workflow will miss the gap between confirmed exploitation and live exposure in their own environments. The programme shift is toward validating exploitability first, then using compensating controls where remediation cannot happen immediately.

For practitioners

• Prioritise exploitability over CVSS Build remediation queues around exposed assets, reachable code paths, and confirmed exploit patterns instead of treating severity scores as the main decision input. Link vulnerability triage to runtime telemetry so teams can see whether a flaw is actually used in production.
• Map repeat CWEs to control owners Assign SQL injection, command injection, code injection, path traversal, and missing authentication findings to specific engineering and IAM control owners. Use a shared review process for input validation, auth checks, and privileged function access so the same pattern is not triaged in isolation.
• Use runtime enforcement as a compensating control Where patching windows are long, block malicious behaviour at execution time and verify that the control does not break legitimate application flows. This is especially important for externally reachable functions that lack authentication or accept untrusted input.
• Treat KEV as the minimum remediation floor Patch everything in KEV quickly, but do not stop there. Add independent exploitation intelligence and internal exposure testing so teams can catch weaknesses that are not yet catalogued but are already being probed.

Key takeaways

• CISA’s data shows that exploitation concentrates in a small set of repeat weaknesses, so vulnerability governance must focus on patterns, not just counts.
• Runtime evidence is becoming the decisive signal for whether a flaw is truly risky in production, especially when AI speeds up discovery.
• Identity and access boundaries matter because missing authentication and over-reachable functions turn software defects into control failures.

Key terms

• Application exploitability: Application exploitability is the degree to which an observed defect can be turned into a working attack against a live system. It depends on deployment context, authentication paths, configuration, and runtime behaviour. A finding becomes operationally important when an attacker can reach it and use it for access, collection, or exfiltration.
• CISA Known Exploited Vulnerabilities Catalog: The CISA Known Exploited Vulnerabilities Catalog lists flaws that are already being used in real attacks. For practitioners, inclusion signals that patching has moved from routine hygiene to urgent remediation because exploitation is no longer hypothetical.
• Stubborn Weaknesses: Recurring classes of vulnerabilities that appear repeatedly across years of disclosure and exploitation data, such as input validation failures or injection flaws. These weaknesses persist because the underlying control problems are architectural and operational, not just patch-related.
• 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.

What's in the full article

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

• CWE-by-CWE breakdown of how runtime detection distinguishes exploitable paths from theoretical findings
• Practical examples of how the vendor blocks malicious behaviour without taking down production systems
• Detailed explanation of where CISA’s KEV list stops and why runtime evidence is needed beyond it
• Implementation context for teams that need to prioritise vulnerabilities before patch windows close

👉 Oligo Security’s full post covers the KEV gap, runtime prioritisation logic, and exploit blocking detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for teams building stronger access control and lifecycle discipline. It helps security practitioners connect identity governance to the broader controls their programmes rely on.