The interesting number in any vulnerability programme has never been how many bugs you find. It's how many days pass between a fix existing and that fix running in production. Too many organisations treat the first number as the scoreboard and the second as someone else's problem, and the arrival of competent AI-assisted vulnerability research is about to make that imbalance very uncomfortable.
Microsoft's security blog has a post on lessons from its FORGE Lab, which is scaling frontier-model vulnerability research from Windows out to the Linux kernel. The write-up covers methodology, hit rates and validation cost, and it is worth reading in full. The trajectory is not ambiguous, and it's worth thinking through what it does to the people who actually run estates.
Automated bug-finding is not new — the economics are
Let's not perform surprise. Coverage-guided fuzzing has been industrialised for years. OSS-Fuzz has been grinding through open source since 2016. syzbot has been firing syscall fuzzing at the Linux kernel continuously and filing reports faster than maintainers can close them. Static analysis has been part of every serious SDL since the mid-2000s.
What a large language model adds isn't raw throughput — it's the ability to reason about code that fuzzers struggle to reach: complex state machines, logic flaws, the kind of bug that requires understanding intent rather than crashing a parser. That moves the cost curve on classes of vulnerability that previously required a scarce, expensive human with a specific obsession. When the marginal cost of a competent reviewer approaches the cost of inference, the volume of discovered-and-reported defects goes up. Not linearly, probably, but materially.
Why a Windows shop should care about the Linux kernel
Plenty of infrastructure teams still mentally file Linux kernel CVEs under "not our problem" because the desktop fleet is Windows and the line-of-business apps are on Server 2022. That assumption died some years ago and nobody held a funeral.
Count the Linux kernels in a typical Microsoft-centric estate: every container host, every AKS node, the Azure Linux images underneath a surprising amount of first-party tooling, WSL2 on developer machines, the firewall, the load balancer, the storage array, the backup appliance, the hypervisor management plane, the ESXi-adjacent boxes, the IP cameras, the UPS management cards. Most of those are vendor appliances where you have no ability to patch the kernel yourself and no visibility into which kernel version you're running. That's the real exposure — not the handful of Ubuntu VMs your team builds and controls.
So when kernel-level findings accelerate, the pain lands disproportionately on appliance vendors, and therefore on you, in the form of a longer wait and a firmware bundle you can only apply during a change window.
The CVE firehose is already past human scale
Published CVEs crossed roughly 40,000 in 2024 and have kept climbing. The Linux kernel became its own CNA in early 2024 and promptly began issuing CVEs for essentially every fix with conceivable security relevance — thousands per year, most of them unreachable in any given configuration, all of them lighting up your scanner.
That was already more than a vulnerability management function could triage honestly. Add AI-assisted discovery at scale and the question stops being "can we fix everything" — it was never yes — and becomes "can we tell, quickly and defensibly, which of these matters in our configuration."
That is a reachability and asset-data problem, not a scanning problem. If you cannot answer "which hosts run this kernel module, with this config flag, exposed to which network" inside an hour, more findings do not make you safer. They make your risk register longer and your engineers more cynical about it.
What I'd actually do about it
None of this is exotic. It's the same discipline, under more load:
- Fix your asset truth first. Kernel versions, firmware levels and container base images, reconciled weekly, not quarterly. Everything downstream depends on it.
- Measure time-to-deploy, not time-to-detect. Track the median days between vendor fix availability and estate coverage, per platform. Report that number to the board instead of a count of open findings.
- Get live kernel patching working where the platform supports it — kpatch, livepatch, the equivalents from your distro vendor. It's the difference between a same-week fix and a three-month reboot queue.
- Put patch SLAs into appliance procurement. Contractual commitment on kernel and firmware currency, with an exit clause. Vendors who can't commit are telling you something.
- Assume the next class of finding is in something you don't build. Your response plan should work when the fix is not yours to write.
The defender's advantage is real but narrow
There's a comforting argument that AI-assisted research favours defenders, because vendors and well-resourced labs will find and fix bugs before attackers reach them. It is only half right. Microsoft, Google and the major open source projects do have the budget, the source access and the CI pipelines to turn findings into shipped fixes.
The advantage evaporates at the point of deployment. A fix that exists in the upstream kernel tree and a fix running on your storage controller are separated by a vendor's release cadence, your change board, and a maintenance window someone will push to next quarter. Attackers don't have a change board. The same tooling that produces fixes upstream will, soon enough, produce reliable exploits for the unpatched tail — and the unpatched tail is where most organisations live.
What this doesn't change
Nothing here alters the fundamentals. Identity remains the dominant initial access vector, phishing and credential theft still outperform memory corruption for most intrusions, and a well-segmented network with enforced MFA and tested backups absorbs a kernel zero-day far better than a flat one with a perfect scanner.
Treat the FORGE work as a signal about volume and velocity, not as a reason to re-architect your programme around kernel bugs. If more findings are coming — and they are — the organisations that cope will be the ones who shortened the distance between "fix exists" and "fix deployed" before the volume arrived, not the ones who bought another scanner.