CISA KEV prioritisation is reshaping vulnerability response

At a glance

What this is: This is a product analysis of how KEV-driven prioritisation changes vulnerability response, with the key finding that attackers concentrate on a small set of exploitable CWEs rather than the full vulnerability catalog.

Why it matters: It matters because IAM, NHI, and security teams need prioritisation models that reflect real exploitation risk, not just theoretical exposure, if they want to reduce blast radius and remediation waste.

By the numbers:

• CWE-787 Out-of-Bounds Write ranked 1st among KEV weaknesses in 2024.
• CWE-843 Type Confusion ranked 2nd among KEV weaknesses in 2024.
• CWE-78 OS Command Injection ranked 3rd among KEV weaknesses in 2024.

👉 Read Oligo Security's analysis of CISA KEV prioritisation and runtime exploit detection

Context

CISA’s Known Exploited Vulnerabilities catalog changes vulnerability management by separating issues that are merely present from issues that are being exploited in the wild. For IAM and security programmes, that distinction matters because prioritisation based on label severity alone often misses where attackers are getting reliable execution paths.

The article’s core point is that runtime context is essential for deciding which weaknesses are truly exploitable in a live environment. That has implications beyond application security, because identity and access teams also have to decide which exposures represent real privilege risk, not just theoretical weakness.

Key questions

Q: How should security teams prioritise vulnerabilities that appear in KEV lists?

A: Security teams should prioritise vulnerabilities by evidence of active exploitation, reachability in the running environment, and privilege impact. KEV signals deserve higher urgency because they represent weaknesses adversaries are already using, not just theoretical exposure. The best programmes combine exploit intelligence with runtime context so remediation effort follows real attack paths, not broad category rankings.

Q: Why do runtime signals matter more than static vulnerability scans?

A: Runtime signals matter because they show whether a weakness is actually reachable, weaponisable, and active in production. Static scans can identify possible flaws, but they cannot reliably distinguish dormant code from exploitable attack paths. That difference becomes critical when the weakness can lead to execution, privilege escalation, or control of a trusted workload.

Q: What do teams get wrong when they rely on top CWE rankings alone?

A: Teams often assume that the most common weakness classes are the most urgent to fix, but KEV data shows adversaries concentrate on a narrower set of exploitable classes. That creates a prioritisation gap where popular but less targeted issues consume attention while real attack paths stay open. Programs need exploitability evidence, not category popularity.

Q: How should identity teams think about exploitable application flaws?

A: Identity teams should treat exploitable application flaws as access-risk events when they can touch privileged services, service accounts, or trusted workload paths. At that point, the issue is no longer only code quality. It is also governance of how execution translates into authenticated control, lateral movement potential, and blast radius.

Technical breakdown

Why KEV changes vulnerability prioritisation

The KEV catalog is a live exploitation signal, not a generic severity ranking. That makes it closer to defender reality than broad CWE or CVE lists, which mix widely exploited weaknesses with issues that are rarely used in active attacks. In the article, Oligo argues that attackers cluster around a small set of weakness types because those classes reliably produce meaningful outcomes such as execution or escalation. For practitioners, that means a program built only around top-ranked generic CWEs will misallocate attention and miss the weaknesses most likely to matter operationally.

Practical implication: move prioritisation from theoretical severity to exploit evidence and live exposure.

Runtime detection versus static weakness scanning

Static analysis can tell you that a weakness exists, but it cannot tell you whether the weakness is reachable, weaponisable, or active in the deployed environment. That is why the article contrasts traditional tools with runtime detection that observes execution context, payload behaviour, and actual exploit attempts. This difference is critical for command injection, deserialization flaws, and memory corruption classes where exploitability depends on how the application behaves in production. The real control problem is not inventorying possible issues, but distinguishing exploitable paths from dormant code-level risks.

Practical implication: validate exploitability in runtime before escalating remediation effort.

Context-aware exploitability and identity risk

Context-aware detection matters because a weakness only becomes a security event when it can be used against the actual workload, identity path, or privilege boundary in place. The article’s framing shows why environmental detail changes interpretation: the same flaw can be trivial in one deployment and critical in another if it reaches privileged execution or trusted service interactions. For identity teams, the lesson is that vulnerability management and access governance are linked. A reachable exploit path becomes far more dangerous when it intersects with service accounts, workload credentials, or broad trust relationships.

Practical implication: evaluate exploit paths in the context of privileges, trust boundaries, and workload identity.

Threat narrative

Attacker objective: The attacker aims to turn a reachable runtime flaw into execution and control inside a real workload, then use that access for broader compromise.

1. Entry occurs when an attacker targets a weakness that is already known to be exploited in the wild, often through injection, memory corruption, or unsafe deserialization.
2. Escalation follows when the flaw yields code execution, privilege escalation, or control of the running workload rather than a simple crash or warning condition.
3. Impact is achieved when the attacker converts that foothold into persistent access, lateral movement, or broader compromise of the environment.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• 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

KEV-driven prioritisation is a control model, not just a reporting model. The article is right to treat CISA’s catalog as more than a list, because it forces defenders to anchor response in actual exploitation rather than generic vulnerability volume. That shift aligns with OWASP-NHI and NIST-CSF thinking: controls should follow operational exposure, not abstract severity. The practical conclusion is that teams must rebuild prioritisation around exploit evidence, not dashboard counts.

Runtime context is the difference between noise and decision-grade risk. Static vulnerability data cannot answer the question that matters most to defenders: can this weakness actually be used here, in this deployment, with this trust model? That is especially important where application flaws touch identity-bearing workloads, service accounts, or privileged automation paths. Practitioners should treat runtime visibility as the point where vulnerability management becomes actionable.

Identity risk now inherits application exploitability. Once a runtime flaw can touch a privileged service, the problem is no longer only AppSec. It becomes identity governance because the attacker is now moving through authenticated trust, not just code execution. That means teams should stop separating exploit management from access control as if they are unrelated disciplines.

Exploitability should drive remediation order, not category prestige. The article’s CWE examples show why top-line rankings can mislead programmes into over-focusing on popular but less actionable issues. A weakness that is heavily exploited but less visible in conventional ranking systems should rise above a more famous class that rarely appears in KEV. The practitioner takeaway is to align remediation SLAs with real-world exploitability.

Runtime weakness prioritisation changes how security investment should be measured. If a tool only reduces alert volume but cannot show whether a weakness is exploitable in the live environment, it is not improving security decision quality. Programmes should measure success by fewer exploitable exposures reaching production, faster confirmation of live risk, and shorter time to contain active exploit paths. That is the standard vulnerability teams should now be held to.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to our Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• That lag reinforces why teams should pair exploitability analysis with 52 NHI Breaches Analysis to understand how exposed credentials and runtime weaknesses combine in real incidents.

What this signals

Runtime exploitability will become the more defensible prioritisation model for security programmes. The article points toward a market where broad weakness lists matter less than proof of what can be used in production. For identity and cloud teams, the important change is that vulnerability response and access governance will increasingly share the same decision set, because a reachable flaw often becomes an authenticated control problem once execution is achieved.

KEV-aligned workflows will push teams toward fewer, higher-confidence remediation decisions. That is useful because alert volume alone does not reduce risk. Practitioners should expect more pressure to show which exploitable weaknesses were removed, which privileged paths were exposed, and how quickly active attack paths were closed after detection.

Identity programmes should treat application weakness management as part of blast-radius reduction. When runtime flaws intersect with service credentials or privileged workloads, the issue is no longer isolated to AppSec. Teams that can connect exploit evidence to identity-bearing systems will make faster, more credible risk decisions than teams that keep those functions separate.

For practitioners

• Re-rank remediation by live exploit evidence Use KEV status, observed exploit activity, and deployment context to place weaknesses into remediation queues instead of relying on generic severity scores.
• Separate dormant flaws from reachable flaws Validate whether a weakness is reachable in the running application before assigning engineering effort, because not every listed CWE is exploitable in practice.
• Tie runtime findings to identity-bearing assets Map exploitable weaknesses to workloads, service accounts, and trusted execution paths so identity teams can see where code flaws become access risk.
• Use exploitability as a board-level metric Report the count of known exploited weaknesses and the time to reduce exposure, not just the total number of open findings.

Key takeaways

• CISA KEV changes vulnerability management by weighting active exploitation over theoretical severity.
• Runtime context is the control point that separates noisy findings from exploitable attack paths.
• Identity and access teams should treat reachable code flaws as blast-radius issues when privileged workloads are involved.

Key terms

• Known exploited vulnerability: A known exploited vulnerability is a weakness that has credible evidence of active use in attacks, not just theoretical risk. In practice, it signals that defenders should treat exposure as immediate and operational, because attackers have already demonstrated value in targeting that class of flaw.
• Runtime detection: Runtime detection is the observation of behaviour while an application or workload is executing, rather than judging risk only from code, package, or configuration inspection. It helps teams distinguish reachable exploit paths from dormant weaknesses and gives better context for response decisions.
• Exploitability: Exploitability is the likelihood that a weakness can be turned into real attacker control in a specific environment. It depends on reachability, execution context, privilege boundaries, and deployed dependencies, not just the abstract weakness category or its generic severity score.
• Blast radius: Blast radius is the amount of damage an attacker can cause after gaining a foothold. In identity and workload environments, it is shaped by privilege scope, trust relationships, and how quickly access can be reduced once a weakness is confirmed as active.

What's in the full article

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

• The exact KEV-aligned weakness classes Oligo detects at runtime across cloud workloads and applications.
• The context signals the vendor uses to decide whether a weakness is exploitable in a live deployment.
• The platform integration approach for teams that want runtime exploit visibility without source-code access.
• The practical reporting angle for engineers and SOC teams that need fewer false positives and faster triage.

👉 The full Oligo Security post covers the KEV weakness ranking, runtime detection approach, and deployment context in more detail.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.