AI and the Artisan Vulnerability Researcher

TLDR; AI will not eliminate vulnerability research. It will eventually make vulnerability research harder, rarer, and more specialized again. We just have no idea when.

‍

You’ve seen it. Read it. The AI vulnerability apocalypse (vulnpocalypse)  is said to be coming at some point, fueled by the familiar mix of fear, uncertainty, and doubt, with a fresh gust from Anthropic’s Mythos Preview and Glasswing announcements. While most of the industry is spending brain tokens on the expected surge in vulnerability volume and the collapsing time between disclosure and exploit, I want to focus on something else:

‍

The longer-term impact on vulnerability research and researchers.

‍

The advances in AI and the vulnerabilities these frontier models are already uncovering are genuinely impressive, even by the standards of the best vulnerability researchers in the world. They are producing a lot of notable bugs, some exploitable, across a range of severities, many surfacing in widely used software and well-trodden codebases that went undetected for years.

‍

This raises a natural question: given where automation is heading, what happens to traditional vulnerability researchers, the people responsible for discovering the CVEs? Will AI replace them? That question matters to me. Vulnerability research is where my career began, and where many others started. The answer will help shape where the industry goes next.

‍

For background, I showed up in cybersecurity around 2000, just before “application security” was really a thing. Back then, almost every web application vulnerability was found manually, usually by a small, collaborative group of researchers working with little more than a browser and the occasional Perl or Bash script as a proof of concept.

‍

Over time, tools improved and knowledge spread. Organizations like OWASP and WASC helped standardize what had once been tribal knowledge. Training classes, white papers, videos, open source tools, and conference talks turned obscure techniques into something teachable and eventually commercial.

‍

Early research into cross-site scripting, SQL injection, CSRF, DNS rebinding, RFC 1918 abuse, and the endless filter evasions popularized by RSnake’s cheatsheet followed the same arc. What was once difficult to discover and exploit became repeatable, then automatable, and eventually routine.

‍

A handful of application security specialists grew into a global community. Today, hundreds of thousands of researchers participate in bug bounty programs, doing work that once required rare expertise. By sheer volume, most vulnerabilities can now be found with automation (DAST and SAST). Machines handle coverage. Humans handle creativity. That is why much of the application security market feels commoditized.

‍

It was the same story in C, even before the Web got big. When writing C code, you allocate memory, write data into it. If you write too much, you overwrite adjacent memory and crash the program. At first, that was just a bug. Only later did it become a vulnerability, once people figured out how to control that behavior and redirect execution.

‍

And once that technique existed, everything changed. Some bugs became exploitable, then reliable, then scalable. Off-by-one errors, NOP sleds, return-oriented programming, heap spraying, use-after-free, and heap overflows turned ‘bugs’ into potentially exploitable vulnerabilities. Once these techniques were discovered, they were taught, refined, weaponized, and repeated. What began as the work of a few eventually scaled to thousands. Automation did not eliminate the problem. It changed where the difficulty lived.

‍

Beyond all the nuance, here’s where we’re at with AI-powered software development: either we’ll eventually end up with software without vulnerabilities, as some people believe, or if you’re like me, you believe we’ll always have software that will always contain some vulnerabilities,  no matter what.

‍

‍

While Marc Andreessen and Matthew Berman are serious people worth paying attention to, I don’t think anyone is seriously claiming we are headed toward perfectly secure code or anything even remotely close, except maybe Google. Or, Bobby Holly (CTO, Mozilla) if we take what he says literally, “The defects are finite, and we are entering a world where we can finally find them all.” No matter how good AI tooling in vulnerability research becomes, some vulnerabilities will always remain, regardless of how proactive the development lifecycle is. And I am skeptical that AI will reliably discover entirely new attack techniques like those listed above, at least before humans do.

‍

If I’m right, and I’m betting heavily that I am, perfect code will never exist.

‍

Now, assume AI is good and will get very, very good at finding bugs, especially exploitable ones, and over time, those will be fixed. Presumably, some fraction of vulnerabilities will remain, and those will require human expertise to find. As AI raises the software security baseline, the bar for researcher skill rises with it.

‍

There are many open questions about how we get from here to there. What will token costs look like relative to the value of a finding? Which classes of vulnerabilities will remain resistant to automation? How long will it take to burn down the global backlog we have been carrying for decades? For me, I’d guess a decade – at least.

‍

As those answers play out, something interesting happens:

‍

The easy vulnerabilities disappear, and finding new ones becomes hard again; not because they are gone, but because the obvious ones are. What remains will be rarer, less understood, and not something you can find with a checklist, scanner, prompt, or agent.

‍

Like the good ol’ days, it will require intense curiosity, tedious persistence, and craft. The willingness to explore boring and obscure system components without a clear path. The ability to push on something unclear until it breaks.

‍

In other words, the artisan vulnerability researcher will return.