Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

KEV-driven vulnerability response: what IAM and security teams need


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 9439
Topic starter  

TL;DR: CISA’s Known Exploited Vulnerabilities catalog shifts prioritisation away from theoretical severity and toward weaknesses attackers are actively using, with 2024 KEV data showing out-of-bounds write, type confusion, and command injection at the top of the list, according to Oligo Security. The practical change is that exploitability, runtime context, and attack-path evidence matter more than broad vulnerability rankings.

NHIMG editorial — based on content published by Oligo Security: Tackling the Top CWEs from CISA’s KEV List with Oligo

By the numbers:

Questions worth separating out

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.

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.

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.

Practitioner guidance

  • 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.

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.

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

KEV-driven vulnerability response: what IAM and security teams need?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 8923
 

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.

A few things that frame the scale:

  • 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.

A question worth separating out:

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.

👉 Read our full editorial: CISA KEV prioritisation is reshaping vulnerability response



   
ReplyQuote
Share: