Let's start with vulnerability prioritization metrics and signals. Many organizations still rely heavily on CVSS, a framework first introduced in 2005 and revised several times since. Fixation on this single severity score is a primary cause of remediation paralysis. Why, in 2026, are we still triaging vulnerabilities by this single metric when EPSS, KEV, and vendor trend scores have been around for years?
No single metric is inherently bad. The main limitation of the commonly used CVSS Base score is that it measures technical severity, not organizational risk. It does not tell you whether exploitation is occurring, whether the asset is exposed, or how critical that asset is. CVSS v4.0 adds more context, but many workflows still rely mainly on the Base score.
EPSS estimates the probability that exploitation will be observed in the wild within 30 days. Its limitation is that it is predictive, not a definitive indicator of current exploitation. A vulnerability may already have public exploit code or confirmed exploitation while its EPSS probability remains low.
KEV reflects vulnerabilities with evidence of real-world exploitation, but it is retrospective. Exploitation may already be happening before a vulnerability is added, and CISA does not necessarily publish the underlying evidence behind every entry.
The practical takeaway is simple: do not choose a single metric and turn it into a religion. Combine signals, and treat prioritization as an exercise in critical thinking rather than score-sorting. Use CVSS for an initial severity assessment. Use KEV to understand what is known to be actively exploited. Use threat and trending signals from your Vulnerability Management (VM) platform for operational prioritization. And always check whether a public exploit is available.
Important note: none of the prioritization methods matter if asset visibility is weak. You cannot prioritize, patch, or accept risk on a system you do not know exists; and in most organizations, the inventory is the weakest link, not the scanner.
Now let us look at how much AI can actually improve vulnerability triage and prioritization. Many organizations are experimenting with it. You take a vulnerability report, feed it into an AI system, and ask: what here is critical? It may produce a reasonable answer. If it sees an internet-facing RCE with a public exploit, it will tell you that this deserves attention.
But here is the problem. If we already know that an internet-facing RCE is being actively exploited, we do not need AI to tell us what to do. We need to remediate it.
AI is more useful when the task is difficult to formalize, the context is ambiguous, or large volumes of data need to be analyzed. For well-defined logic, a deterministic rule or simple Python script is often cheaper, simpler, and more predictable.
Another point is autonomous agents. This is one of the mainstream narratives right now: agents for automated patching, report analysis, and perimeter monitoring.
There is a risk that once the phrase "autonomous workforce" enters the room, headcount gets cut. And that is a very plausible outcome. More importantly, automated patching is not the same as "press a button and hope for the best." Proper automated patching requires policies designed by qualified people: what can be patched automatically, what cannot, and which software can be updated on which hosts.
If you build those rules into the system, automated patching can work very well. Slap the label "auto-patching, turned on for the whole environment" on it without that groundwork, and you are setting yourself up for a 3 a.m. incident call.
Some say Exposure Management is simply Vulnerability Management 2.0 with a new price tag. Others argue that it is something fundamentally different. Some Gartner-style packaging is certainly involved. A crouton may not cost $100, but a croissant can. In practice, the model often looks broadly similar to the traditional Vulnerability Management lifecycle, but with a wider scope and more emphasis on understanding and, where possible, validating whether an exposure is actually exploitable.
If you strip away the marketing, two real pillars remain:
First: exposure means weakness in a broader sense. It is not limited to CVEs. It can include misconfigurations, exposed services, excessive app permissions, identity issues, risky network relationships, and other conditions an attacker could use. The scope is much broader than traditional Vulnerability Management.
Second: prioritization changes. Instead of fixing vulnerabilities simply because they exist on a host, you consider whether they create meaningful paths to important assets. That may involve attack paths, exploitability, asset criticality, reachability, threat intelligence, and existing controls. For example, fixing several weaknesses that break major paths to a critical system may matter more than fixing an isolated CVSS 9.7 vulnerability.
If that is what you are actually implementing, Exposure Management can be valuable. If Exposure Management is just a new label for an old scanner, it is wasted money.
One problem is that much of the open-source ecosystem does not have large bug bounty programs. Chrome pays substantial rewards for certain security bugs, so naturally it attracts a lot of researcher attention. Many critical parts of the Linux stack do not offer comparable rewards. As a result, researchers may have less financial incentive to look for vulnerabilities there, which can mean some issues remain undiscovered and unfixed for longer.
At the same time, the Linux kernel and the broader Linux stack are patched every month. The numbers can be surprising, with hundreds of kernel CVEs appearing over relatively short periods. At first glance, it can seem like the system is getting out of control.
Part of that growth is bureaucratic. The Linux Kernel project gained its own CVE-issuing authority in 2024 and now assigns a CVE to nearly every bugfix that could plausibly have security relevance—a deliberate, documented policy on their part, since the kernel team cannot always tell in advance whether a given bug is exploitable. But that still does not answer the broader question: why do highly-exploitable vulnerabilities continue to appear, sometimes with working exploits available quickly? Local privilege escalation vulnerabilities such as Dirty Pipe are obvious examples, along with entire families of similar flaws.
Some argue that the Linux kernel has grown so large and complex that a fundamentally different design may eventually be worth considering. Some researchers and engineers favor smaller kernels, stronger isolation, and architectures designed around security from the beginning rather than continuing to expand the traditional monolithic model.
A useful example here is seL4. It is a security-focused microkernel with formal mathematical proofs that its implementation satisfies key correctness and security properties. The idea is very different from simply hardening Linux: keep the trusted kernel small, enforce strong isolation between components, and build the rest of the system around explicit security boundaries.
Traditional vulnerability management does not always work well in containerized environments. The main reason is that containers are often ephemeral. A container may exist now and disappear five minutes later, so trying to identify and scan every individual running container is often inefficient.
A better approach is to focus heavily on container images. A container image security solution can scan images as part of CI/CD before deployment, identify vulnerable packages and dependencies, and prevent images that violate security policy from reaching production. Major cloud platforms support this model through services such as Amazon ECR image scanning and Google Artifact Analysis.
Pre-deployment scanning is not enough, however. Vulnerability intelligence changes after an image has been built, so images that remain in use should continue to be reassessed as new CVEs and package data become available.
Image scanning should also not replace runtime visibility. Long-lived workloads, Kubernetes configuration, runtime behavior, secrets, and changes in workload state can introduce risks that are invisible in the original image alone.
Cloud infrastructure also requires a different approach from traditional internal network scanning. Simply deploying agents everywhere and scanning cloud hosts as if they were servers in an on-premises data center can leave important context out. Modern cloud security increasingly relies on cloud APIs, configuration data, workload metadata, Kubernetes API data, and agentless assessment alongside traditional agent-based scanning. Microsoft Defender for Cloud supports agentless vulnerability assessment and Kubernetes posture analysis across supported Azure, AWS, and Google Cloud environments.
There is a common belief that should not be dismissed entirely: IT teams sometimes appear to sabotage the vulnerability management process. Let's break down the objections VM teams often hear from IT admins.
"We do not understand this. Bring it in a different format, with specific commands." By the time everyone agrees on the format, two months have passed.
"Your scanner is wrong. These are false positives." Another month goes into proving that the findings are valid.
"Fine, the vulnerability exists, but it is not exploitable." Now you have to demonstrate a working exploit.
"Okay, you proved it. Now let us go through the other 35,000 vulnerabilities in your report."
Can this really be called sabotage? Probably not in most cases. IT teams have their own priorities, operational responsibilities, and constraints. Then someone arrives with a massive vulnerability report and asks them to fix issues that may not be clearly prioritized, explained, or connected to business risk.
The main takeaway is that proving exploitability should not be required for every remediation decision. What works better is a formal process backed by clear policies, risk-based prioritization, remediation SLAs, ownership, and escalation rules. Instead of saying, "Look, I managed to exploit your host in a test environment," the message becomes: "Starting Monday, this is the remediation policy. Here are the deadlines, responsibilities, and escalation rules."
A workable SLA is specific, not aspirational. For example, a critical vulnerability with a public exploit may require remediation within a defined number of days, while exceptions must be formally documented, approved, risk accepted, and tracked.
Paperwork does not solve everything, but it can solve a surprising amount. And that already matters.
Compliance can also create leverage when the requirement genuinely applies. PCI DSS, HIPAA, SOX, GDPR, and similar frameworks can give remediation requests more organizational weight when the affected system, data, or control falls within their scope. But compliance should support the risk argument, not replace it. Citing a regulation that does not actually apply can damage the credibility of the VM program.
Every large infrastructure environment has legacy systems: old industrial control systems, medical equipment, specialized hardware, and software that may be 15 years old or more. Sometimes patching is too risky because an update could disrupt the system. In some cases, even active vulnerability scanning can be risky because the device may not tolerate unexpected traffic or probing safely.
Vulnerability management in these environments is difficult, and there are no perfect solutions.
The realistic approach is:
Record that the vulnerability or exposure was identified, that the appropriate owner was informed, what compensating controls were applied, and what residual risk was formally accepted.
Use network segmentation, traffic monitoring, strict access controls, and other compensating controls to reduce the likelihood and impact of compromise.
If the system cannot be patched or safely scanned, assume that residual risk remains and make sure detection, containment, and incident response procedures account for it.
Who actually owns that accepted risk? Often the asset or business owner, depending on the organization's governance model. But individual owners change roles, leave the organization, or inherit different responsibilities. The key question is whether a formal process preserves accountability over time. In many organizations, that process is still weak.
And revisit these exceptions regularly. A system classified as "unpatchable" three years ago may now have a vendor update, a replacement path, a maintenance window, or a safer mitigation available.
Vulnerabilities can remain in infrastructure for years because remediation is often where vulnerability management breaks down. Scanning the environment is manageable. Identifying high-priority findings is manageable. Creating tickets is easy. The difficult part is understanding why a specific vulnerability is still open three months later.
That is where mature VM programs are built. Responsibilities must be clear, priorities must make sense to everyone involved, remediation needs enough resources, and SLAs must be backed by management.
Tools matter, but process and culture matter more. The real goal of vulnerability management is not detection; it is reducing risk through remediation, mitigation, or formally accepted exceptions.
When remediation stalls, better dashboards rarely solve the problem. What helps is direct coordination with IT teams, clear ownership, realistic deadlines, and formal leadership support.