AI in Cybersecurity: Why Context-Driven Risk Scoring Is the Only Way Forward
Every scanner spits out a list of "critical" findings. Every CISO stares at that list, knows the team can't possibly fix all of it, and picks the ones with the biggest red numbers. The logic feels sound. It is not.
FIRST's 2026 Vulnerability Forecast projects a median of roughly 59,000 CVEs published this year. That is not a backlog you burn down over a long weekend. It is a firehose that makes severity-sorted spreadsheets into fiction. Meanwhile, more than 48,000 CVEs landed in 2025 alone—a 21% jump over 2024—and the NVD analysis pipeline managed full enrichment on only 28% of those. So a growing share of your "critical" tags are provisional, possibly wrong, and definitely incomplete.
The uncomfortable truth: sorting by CVSS is not prioritization. It is a spreadsheet sort. Real prioritization requires context—what this vulnerability means here, on this system, in your environment, at this moment. And artificial intelligence in cybersecurity is no longer a luxury when you're trying to process that context at scale.
The Problem With Sorting by Severity Alone
CVSS was built to measure technical severity: attack complexity, privileges required, potential impact on confidentiality or integrity. It produces a number between 0 and 10. It does not consider whether anyone is actively exploiting the flaw right now. It does not know whether the affected system faces the internet. It does not know that system barely matters to your business.
Here's what happens in practice. A scanner hands you 400 "critical" CVEs. Your team can realistically close 40 this month. If severity is the only filter, you end up patching a low-value staging server while a moderately scored but actively exploited flaw sits untouched on an internet-facing production system. The backlog does not shrink. It just rearranges itself.
Wiz data tells the story in numbers: 80% of cloud intrusions in 2025 started with a vulnerability, exposed secret, or misconfiguration. Not a zero-day. Not a nation-state tool. Something already on the list, already flagged, ranked below 200 other findings by a number that was never designed to answer "what should we fix first?"
How Artificial Intelligence Is Used in Cybersecurity: From EPSS to Attack Paths
This is where artificial intelligence and cybersecurity intersect most directly in the vulnerability management space. The question isn't theoretical—it's operational. How do you process 59,000 CVEs with a team of six?
EPSS, the Exploit Prediction Scoring System, uses machine learning models to estimate the probability that a vulnerability will be exploited within the next 30 days. It outputs a score between 0 and 1. A finding with a mid-range CVSS score and a high EPSS score deserves attention sooner than a "critical" CVE nobody is actively targeting. That is AI doing what a human triage analyst simply cannot: processing exploitation likelihood across tens of thousands of data points, in real time, without fatigue.
Modern platforms push further. Wiz's Security Graph maps every vulnerability to the resources, identities, network paths, and data around it, revealing attack paths and toxic combinations that represent actual risk rather than theoretical severity. Their eBPF-based sensor adds runtime validation, confirming which vulnerable packages are actively loaded and executing versus merely installed. That distinction matters enormously: a CVE on a package that isn't running in production is a finding you can confidently defer. A CVE on a running, internet-facing, over-permissioned workload is something else entirely.
Some platforms now layer AI-powered remediation guidance on top of this, generating fix recommendations tailored to the affected resource and its context, so developers can act without reverse-engineering every finding from scratch. That is how AI is used in cybersecurity in the most practical sense I've seen: not replacing the analyst, but eliminating the 80% of triage work that never should have required a human in the first place.
The Context Layers That Give Scores Meaning
Two organizations can have the exact same CVE, the exact same CVSS score, and completely different real risk. The difference is context. Three layers matter most.
Asset criticality. Not every server carries the same weight. A flaw on a decommissioned test box is not the same problem as the same flaw on your production database. Asset context asks: if this system went down or got compromised, what would it cost you? The fix is tying your inventory to business function, tag systems by what they touch: customer data, payment flows, authentication, source code. A vulnerability on a high-value asset always outranks the same vulnerability on a low-value one, even at identical CVSS.
Attack surface. Reachability changes everything. A vulnerability buried three network hops behind a firewall, with no direct path in, carries different real-world risk than the same flaw sitting on a system reachable in one step. Mapping attack paths, not just individual assets, reveals which vulnerabilities sit on an actual route to something valuable.
Cloud context. Cloud environments move fast, and that speed changes how a vulnerability behaves. A misconfigured storage bucket or an overly permissive IAM role can turn a moderate vulnerability into a direct path to sensitive data. The same CVE can carry low risk on an isolated VM and high risk on a serverless function with broad permissions. Static, point-in-time ranking cannot keep pace with that dynamism.
CISA KEV: The Signal You Can't Ignore
The Known Exploited Vulnerabilities catalog lists CVEs with confirmed, real-world exploitation. If something on your list is already in KEV, it moves to the top regardless of what CVSS says. A CVE being weaponized in the wild changes its priority even if its severity score hasn't moved.
KEV is reactive and limited in scope, it only tells you what attackers have already done somewhere, not what they'll do to you specifically. But that's still infinitely more actionable than a raw severity number. Real-time feeds like KEV surface the issues under active exploitation worldwide, and when you pair that with environmental context, whether the affected asset is reachable, what it can access, you get something close to a defensible priority queue.
Building the Framework: A Five-Layer Approach
A working framework does not throw out CVSS. It stops treating CVSS as the whole answer and stacks signals on top. Here's the order that holds up in practice:
- Severity as a floor. Pull the CVSS base score. Use it to sort the noise, not to make the final call.
- Exploit likelihood via EPSS. Estimate probability of exploitation in the next 30 days. A high EPSS score should override a moderate CVSS.
- CISA KEV cross-check. Confirmed active exploitation is your highest-confidence urgency signal.
- Environmental context. Asset criticality, network exposure, IAM permissions, data sensitivity. This is the step most teams skip, and it changes the answer the most.
- Composite score with routing. Combine the layers into one number your team can act on, route it to the right owner with an SLA attached. A score that does not lead to a routed, owned action is just a report nobody reads.
A prioritization matrix, likelihood versus impact, helps communicate this to non-technical stakeholders and supports risk-acceptance decisions. It works for quarterly risk reviews, incident response planning, and the governance layer of a risk-based vulnerability management program. But the matrix is a communication tool. The five-layer process is the operational engine.
What Good Output Looks Like
The endpoint of all this prioritization isn't a dashboard with color-coded charts. It's a ranked queue with clear ownership, specific remediation guidance, and SLA tracking, routed directly into developer workflows. Not a CVE description. Not a generic advisory. A fix instruction for a specific resource, with context about why it matters, assigned to the person who can actually change the thing.
Leading teams also incorporate AI-powered remediation guidance that tailors the fix recommendation to the affected resource and its surrounding context. The goal is to reduce time-to-action, not time-to-report.
The Bottom Line
Vulnerability severity and vulnerability risk are not the same thing. The industry is still catching up to that sentence. Teams that sort by CVSS are playing a game with rigged dice, patching low-risk systems while actively exploited flaws on internet-facing assets wait their turn behind 300 "more critical" findings that will never see a real exploit attempt.
The organizations that survive the next 59,000 CVEs won't be the ones with the biggest teams. They'll be the ones that understand context is the only input that converts a score into a decision, and that AI in cybersecurity is what makes processing that context possible when the volume is measured in tens of thousands.
