I keep coming back to the same uncomfortable thought: the vulnerability backlog was already too large before attackers gained cheap, widely available AI assistance. Now the industry is asking security teams to move faster inside a system that was designed around slower assumptions.

ENISA says more than 48,000 vulnerabilities received CVE identifiers in 2025, a 22% increase over the prior year. That number is useful as a signal, but it is not itself a risk score. A long list of findings does not tell me which business process is exposed, which internet-facing system is reachable, or which weakness an attacker can turn into access before my team finishes its next meeting.

What has changed is the pressure around the list. AI can help attackers summarize technical disclosures, compare patched and vulnerable versions, adapt public proof-of-concept code, write convincing lures, and troubleshoot their own failures. Google Threat Intelligence recently described adversaries moving from simple prompting toward agentic workflows and automation. Verizon’s 2026 DBIR likewise reported that vulnerability exploitation had become the leading breach entry point in its dataset, with AI helping compress exploitation from months to hours.

My conclusion is not that every new CVE is an emergency. It is that the clock is becoming a more important part of vulnerability management than the score attached to the finding.

The queue is becoming a race

Traditional vulnerability management taught teams to collect, normalize, score, assign, remediate, and verify. That process is still necessary. It is also dangerously easy to mistake process completion for risk reduction.

A queue is a representation of work. Risk is a representation of possible harm. Those two things overlap, but they are not the same. A critical vulnerability on an isolated test system may be less urgent than a medium-rated flaw on an exposed appliance connected to identity infrastructure. A newly disclosed weakness with no known exploitation may deserve watchful preparation; an older weakness that suddenly appears in an attacker toolkit may deserve immediate containment.

AI makes this distinction harder because it increases the number of things an attacker can try and reduces the cost of trying them. The practical result for vulnerability teams is not simply “patch more.” It is that teams need better signals about exposure, exploit activity, asset importance, compensating controls, and the likely path from technical weakness to business consequence.

I expect the best teams to spend less time arguing about whether a score is high enough and more time answering four questions: Is the asset reachable? Is the vulnerable function enabled? Is exploitation active or becoming easier? What would an attacker gain next?

What vulnerability teams will have to change

First, vulnerability management will become more tightly connected to attack-surface management, identity, cloud, and incident response. A scanner cannot tell the whole story. The team needs to know whether an asset is public, whether its credentials are privileged, whether it sits on a path to sensitive data, and whether there are signs that someone is already testing it.

Second, remediation will become more tiered. Some findings will get a patch. Others will get an emergency configuration change, an access restriction, a service shutdown, a compensating control, or a decision to replace the product. “Patch everything” sounds responsible, but it becomes an evasion tactic when it gives leaders the impression that the organization has a plan while the genuinely dangerous exposures wait behind thousands of lower-consequence tickets.

Third, teams will use AI on defense, but I do not think the answer is to hand an agent unrestricted authority over production. AI is useful for deduplicating findings, explaining exploit prerequisites, mapping dependencies, drafting change plans, checking whether a fix actually landed, and producing evidence for review. The control point should remain human judgment around scope, business impact, and irreversible action.

Finally, verification will matter more than intent. A ticket marked remediated is not proof. Teams need to confirm the version, configuration, reachable path, and residual exposure. In an AI-compressed attack window, stale evidence is a security problem of its own.

How leaders should understand risk

Leaders do not need a daily tour of CVE identifiers. They need a reliable picture of where the organization can be entered, what can be reached afterward, and how quickly the organization can reduce that exposure.

I would ask for a small risk view built around business services rather than scanner totals. Show the exposed assets supporting revenue, operations, identity, and sensitive data. Show the subset with known exploitation or credible weaponization paths. Show the age of the exposure, the owner, the containment option, and the evidence that the control works. Then show the exceptions that leadership has consciously accepted.

This changes the conversation from “Why is the backlog still large?” to “Which paths to material harm are open, who owns them, and what decision are we making about each one?” That is a much more honest executive question.

Leaders should also resist the temptation to treat AI as either a magical defensive multiplier or an unavoidable apocalypse. The facts point to something more ordinary and more demanding: attackers are getting productivity gains, and defenders must improve their own decision quality without surrendering control. AI can reduce analysis time. It cannot decide what the business is willing to lose.

The wisdom I would keep

My advice is to stop measuring maturity by how quickly a team closes tickets. Measure whether the organization can identify its most consequential exposure, make a proportionate decision, and prove that the decision changed reality.

Keep the vulnerability queue, but do not worship it. Keep severity scores, but do not confuse them with business risk. Use AI to widen analysis and shorten repetitive work, but put approval gates around production changes and preserve an evidence trail. Build relationships between vulnerability management, asset owners, identity teams, cloud teams, and incident responders before an urgent finding forces the introduction.

The volume of vulnerabilities may keep rising. The volume of attack attempts may rise with it. We are not going to win by pretending the list can become empty. We win by becoming much better at recognizing which open door matters, how quickly it can be used, and what action closes it for real.

Sources