Disovery is not the bottleneck!

There is a seductive logic to the current surge of optimism around AI-supported (or even entirely AI-based) vulnerability discovery. If the bottleneck in software security has always been the limited number of human experts capable of auditing code, then a tool that can scan millions of lines overnight and deliver significantly better results than traditional software security assessment tools seems like a rather impressive step forwards to ensuring the security of information systems.

And from what we can see in reporting and on social media, security researchers are already demonstrating that large language models and specialized AI systems can find real, previously unknown vulnerabilities in production-grade software with large, comparatively mature codebases. They can sometimes even generate proof-of-concept exploits or propose patches.

The main problem is that this logic is based on a fundamental misunderstanding of the situation at hand. Independent security researchers, bug bounty programs, internal red teaming, static analysis tools, fuzzing .. all of these continually identify flaws in our software. The CVE-system grows by thousands of entries each year. The security industry (or IT industry in general, for that matter) has never suffered primarily from a shortage of discovered vulnerabilities.

It instead suffers from a chronic, structural inability to act on the ones it already knows about. Both my highly subjective professional experience and the public reporting about security breaches in the past couple of years show that a significant fraction of systems breached in major incidents are compromised through vulnerabilities for which patches already existed, sometimes for years.

CISA maintains a list of known exploited vulnerabilities, flaws that are actively being used against real targets by a variety of different threat actors. Some of the products affected by the vulnerabilities on this list have had patches available for months or years that would fix the issue, but attackers continue to happily abuse the problems because the patches simply aren't being applied. The attackers rarely need 0-days, most of the time they can rely on the world's slow and extremely uneven response to one-days.

The problem is decidedly not that we lack knowledge of the vulnerabilities. It is that knowing about them and fixing them seem to be almost entirely separate phenomena, governed by entirely different forces.

Why we don't fix things ..

Patching software is, unfortunately, not merely a technical fact. That becomes clear once you take a look at the lifecycle of a patch in a real-world organization. It is rarely a simple matter of running an update.

Enterprise software environments are intricate ecosystems of dependencies. A patch to a foundational library can break applications built against older versions of that library. Organizations running critical infrastructure frequently cannot apply patches without extensive testing cycles that can sometimes take weeks, because the patch breaking a production system is simply not a possibility for these entities.

In some regulated entities, patching certain systems requires re-certification processes that are measured in, at best, months, not days. And specialized software was often not designed with either security in mind or with the intention to be easily patched - or, as is the case with some embedded systems or medical devices, can't be updated at all.

But even if there are no technical reasons that would oppose swift patching, there are other issues that might interfere. Large organizations tend to accumulate software the way old houses accumulate walls - through decades of construction, renovation, and neglect, with the original architects often long gone.

Which means it's entirely realistic to end up with a situation where there's a patch for a legacy application that was acquired through a merger, running on a platform no longer supported by any vendor, documented only in the institutional memory of someone who retired - oh, and by the way, seven different departments rely on it. Who's the owner of the system? Who's responsible for patching it?

Assuming that such a system falls under the scope of a dedicated team, security or operations, that is responsible for patching .. well, those teams tend to be under-resourced relative to the scope of their environment. They have to prioritize, doing so under competing pressures from business continuity, development timelines, budget cycles and compliance requirements.

When this under-resourced and overworked team finally finds time to patch a system, they might find themselves out of luck. For a significant proportion of vulnerabilities in commercial software, the affected organization cannot patch anything on its own. They must wait for the vendor to issue a fix, and their timelines vary enormously. From days to years, and sometimes to never, everything is possible.

There's more!

Because of these organizational, economical, and architectural restrictions for dealing with software flaws, the increased discoverability of vulnerabilities does not necessarily immediately translate into faster rates of fixing.

For the sake of the argument, let's assume that an AI-based vulnerability assessment tool can not just scan a codebase for vulnerabilities, but can take care of everything that usually follows after that.

That tool, on discovering a critical vulnerability in a piece of widely used software, still has to route that finding through coordinated disclosure, wait for a vendor patch, communicate the risk to thousands of affected organizations, and hope that their IT teams have the budget, the access, the testing infrastructure, and the organizational will to act in a timely manner. None of those steps are accelerated by the initial faster discovery.

Attackers, on the other hand? They benefit immediately. A vulnerability in software is exploitable more or less the moment it is found, whether or not a patch exists. If AI tools allow attackers to discover vulnerabilities faster than defenders can respond to them, then the state of security gets worse, not better, despite more vulnerabilities being known.

Don't yell at me please!

This post is not trying to make an argument against AI-supported or -powered vulnerability discovery. Better discovery tools genuinely matter, particularly for the open-source software that underlies significant parts of the modern Internet and that has historically received inadequate security scrutiny. The point I'm trying to make is that discovery is necessary and cool and all of that, but discovery alone is nowhere near sufficient.

I know that I'm beating a dead horse here, but what the security ecosystem actually needs (alongside better discovery - again, please don't yell at me), is investment in the boring, unglamorous, structurally difficult problems that govern whether vulnerabilities get fixed.

It needs better software composition analysis tooling that makes it easier for organizations to know what they are running. It needs funding mechanisms for open-source maintainers who are currently responsible for critical software while operating with zero resources. It needs regulatory frameworks that create actual accountability for vendors who sit on vulnerability reports. It needs architectural investment and systems designed for "updateability" from the ground up. And it needs honest organization conversations about the legacy systems that cannot be patched and need to be replaced.

---

The "AI optimists" are not wrong that something significant seems to be happening in vulnerability research. But they are wrong about where the bottleneck is. We are not drowning in undiscovered vulnerabilities that a sufficiently smart tool will finally surface.

We are drowning in discovered ones that the ecosystem does not have the structure, the resources, or sometimes the incentives to fix. This is a hard problem that is not going to yield to a better scanner. As great as that would be.