A few years ago, once a critical vulnerability was disclosed, companies still had a relatively predictable window of time to react. Today, a vulnerability may be exploited before most defenders even know it exists. While attackers are benefiting from AI-driven automation, companies need a new strategy for vulnerability management.
In the „good old days“, someone first had to analyse a newly discovered flaw, develop a working exploit, prepare the infrastructure, and only then start exploiting it at scale. The process could take several days or even weeks, giving defenders valuable time to spread awareness and release a patch.
Recent years have turned this system on its head, and with AI-powered automation, the number of published CVEs is growing at a record pace. Regularly opening a report and checking what has been added is no longer enough. Vulnerability management is shifting from routine IT maintenance to a continuous process where accurate information, automation, and speed of response are what matter. explains Jozef Rusnák from Binary Confidence
The number of discovered CVEs has skyrocketed with AI
The CVE Program recorded approximately 6,500 published CVE entries in 2016. In 2025, the figure exceeded 48,000, while the forecast for 2026 is more than 75,000 vulnerabilities. In less than a decade, annual output has therefore increased more than tenfold.
For IT and security teams, this means a massive increase in workload. Every additional operating system, firewall, VPN concentrator, browser, framework or third-party tool creates another stream of vulnerabilities that needs to be monitored.
Manually going through everything that appears each day and then determining whether a particular flaw actually affects your infrastructure is becoming unrealistic in more complex environments.
AI is shortening the path from vulnerability to working exploit
The growth in the number of CVEs is only one half of the problem. The other is speed. AI can now assist with source-code analysis, identifying potential flaws, analysing patches, and developing and testing exploits.
CrowdStrike warned as early as 2025 that generative AI could significantly accelerate vulnerability research and the iterative development of exploits. In 2026, Google Threat Intelligence Group even described the first zero-day exploitthat it believes was developed with the help of AI.
Not every new CVE will automatically become exploitable five minutes after publication. But it is clear that tasks which once required significant manual work from a specialist can increasingly be automated. Defenders are therefore no longer competing only against people, but against an increasingly automated process.
The time available to respond has moved into negative territory
Time-to-exploit, meaning the time attackers need to effectively exploit a known vulnerability, fell in some cases from 63 days in 2018–2019 to 32 days in 2021–2022. This year, the metric effectively “broke through the floor”, with M-Trends 2026 reporting an average time-to-exploit of -7 days.In other words, vulnerabilities are now being exploited, on average, days before a usable patch is released.
For vulnerability management, this represents a paradigm shift. Companies can no longer assume that they will have several days to react between the disclosure of a problem and its exploitation.
Vulnerability management starts with an inventory of everything you have
“It is difficult to patch something when you do not even know it exists in your environment, and that is exactly where chaos begins. One employee has one browser version; another has a different one. A developer installs a tool they need for a particular project,” says Jozef Rusnák, stressing that things can happen in an ordinary corporate network without central IT even being aware of them.
Even the best list of newly published CVEs will not help a company that does not know where the vulnerable product is located. Good vulnerability management therefore depends on asset and configuration management. You need to know which servers, workstations and network devices you operate, which operating systems they run, and which applications and specific software versions are installed on them.
Set priorities for vulnerability patching
Not every vulnerability will bring your infrastructure to its knees. If the organisation does not use the affected product, or a newly published CVE concerns a tool located deep inside the internal network, the priority is lower. If, however, a critical vulnerability appears on an external firewall, VPN gateway or another internet-facing device, fixing it becomes immediately relevant.
Information must arrive continuously, but it also needs to be filtered according to the specific technologies the organisation actually uses. Effective vulnerability management therefore needs to connect vulnerability intelligence with the asset inventory and the context of the individual organisation. Only then can you decide what must be addressed today, what can wait and what does not affect the company at all.
There must be a closed process from CVE discovery to verification of the fix
At every step, it must be clear who is responsible. Someone has to monitor newly disclosed vulnerabilities. Someone has to assess their relevance and severity. The information must reach the person who can implement the remediation, and the organisation then needs to verify that the issue has actually been resolved.
The final steps of this process are often the most difficult. An older version of an application may be tied to production, the user may not want to update it, and the device manufacturer may not yet have a patch available. “Vulnerability management is effective only when it is a real organisational and technical process. At today’s volume of newly discovered vulnerabilities, comparing a list of CVEs with a list of your assets is simply not enough,” stresses Jozef Rusnák.
A SOC can monitor the problem even when nothing appears to be happening
We usually associate a Security Operations Center primarily with attack detection. Its advantage, however, is that it already has security context about the customer’s environment and operates continuously. A SOC can therefore keep track of new vulnerabilities, assess their relevance and get the information to the right person before an incident occurs.
This is particularly important for devices that remain outside administrators’ everyday attention. A server running outdated software may be visible during routine administration. A firewall or another network device, however, can continue operating for months without anyone receiving a warning that its firmware contains a critical flaw.
How we handle vulnerability management in the Binary Confidence SOC
At our Security Operations Center, we have designed part of the process to combine automation with analyst judgment. We map the technologies our customers use. An automated tool reviews available information about newly disclosed vulnerabilities every day and prepares a SOC overview relevant to those technologies. An analyst then evaluates what is genuinely serious and what actually affects the specific customer.
The subsequent distribution is automated as well. The analyst determines which customers are affected, and the notification can then be sent without manually rewriting and forwarding individual messages. In a process that once required many routine steps, the human analyst is left primarily with the part where judgement matters most: assessing risk and setting priorities.
With today’s volume of vulnerabilities, that is precisely the point of making the process more efficient. Vulnerability management should not create more work. It should separate the problem that genuinely affects you from the thousands of problems that do not, as quickly as possible.
This activity is supported by the European Cybersecurity Competence Centre (ECCC) as part of the project under grant code 101145856, and by the Ministry of Investments, Regional Development and Informatization as part of the state programme of the Recovery and Resilience Plan of the Slovak Republic under project grant code 17I04-04-V02-00001.
