On finding vulnerabilities and shipping fixes

 August 17, 2026

Over the last year, I’ve watched AI models and tools that find vulnerabilities in code take a central role in security industry communications. Every few weeks, a new product announcement promises impressive results, such as AI tools that detect SQL injection, spot memory corruption bugs, identify logic flaws at scale, or chain tens of known vulnerabilities together. This can be impressive for attack purposes, but it is more an interesting novelty than defensive security.

For most organizations, the problem is their ability to fix issues, not finding vulnerabilities. And the challenge is not just fixing them, but doing it quickly and consistently across an estate of applications written in different languages and running on non-coherent platforms.

Even before AI entered the picture, organizations had ways to find vulnerabilities. Static analysis, dynamic analysis, dependency scanners, penetration testing, bug bounty programs, and CVE databases have been around for years. The average enterprise security team already has more findings than it can act on. Every company I have worked with ran security scans of its applications every so often (usually monthly or quarterly) and found hundreds, if not thousands, of vulnerabilities in production each time. If they add AI-powered detection on top of that, the findings will increase, but their security posture might not improve.

In my experience, the way companies manage vulnerabilities is very similar, regardless of their size. A vulnerability is identified, a ticket (or worse, an email!) is created, and it enters a queue. Those tickets are then prioritized in prioritization meetings; every change has to go through Change Advisory Boards, and they’re finally deployed in maintenance windows and on deployment schedules. These processes were designed for a world where changes happen infrequently and deliberately.

The consequence of those slow, convoluted processes is that even important vulnerabilities can take weeks or months to reach production. This is because these processes focus heavily on not breaking production and not at all on ensuring high deployment speed.

In the modern world, where it is very easy to create exploits, also thanks to AI, it is critical to minimize the window between a vulnerability becoming known and the fix reaching production. Shrinking this window is the most impactful thing most organizations can do for their security posture.

To ship a fix to production at scale, you need a full set of capabilities. The first is automated Continuous Deployment. The second is a Continuous Integration process with comprehensive automated testing, so you can be confident a patch will not break anything. Though this only holds at the single-application scale.

To scale this to an enterprise level, you need a third capability: the complete identification of dependencies and their versions, and the ordered rebuild of hundreds or thousands of them with minimal or no human intervention.

Beyond the technical process, the organization needs a culture and governance model that doesn’t require a week of approvals to ship a one-line fix for a critical vulnerability.

Each of these is an investment that pays off far beyond security. They are the same capabilities that let you ship features faster, respond to incidents more effectively, and operate with less toil. Security is one of many beneficiaries of that operational maturity, alongside faster feature delivery and better incident response.

Only the organizations that have already invested in the capabilities needed to ship fixes in production quickly will benefit from AI-powered security tools. Other organizations can start adopting AI-powered security tools. Still, they need to understand that their value will be limited (or zero) as long as they don’t invest in their processes and reach high maturity quickly.

I understand why AI vulnerability detection gets the attention. It is novel, technically impressive, and makes for great conference talks. Deployment pipelines, automated testing, and change-management reform are boring by comparison. They also determine whether your applications actually get safer.