Vulnerability Research Isn’t “Cooked” But the Old Model Is

Last week on ESW we discussed a recent blog post, Vulnerability Research Is Cooked, published by Thomas Ptacek. In the piece, the author argues that AI is about to commoditize vulnerability discovery to the point where the entire discipline collapses under its own success.

It’s an interesting conclusion, and one that corresponds to many cybersecurity practitioners’ intellectual proclivities. But the reality of AI in its current and near-term state, as well as security practitioners’ operational proclivities, render the argument incomplete.

In full disclosure: the news segment on ESW last week was spur-of-the-moment. I’ll spare you the behind-the-scenes technical difficulties drama, but let’s just say we didn’t have a lot of prep time. My comments during recording, therefore, were based on a quick reading. After re-reading and thinking about this post in more depth, I think my initial reaction stands: AI advances vulnerability discovery substantively, and largely for the better. But the problem isn’t discovery—anyone operating in this world knows that raw findings are too plentiful to be useful. That’s why innumerable vendors exist: to contextualize and prioritize the overwhelming volume of findings to the point of usefulness on a per-business basis.1

But digging deeper into this article, there’s another aspect to consider: How can and should operations teams change in the face of these vendor-supplied (or custom-built) AI-assisted tools that organize and operationalize vulnerability research?

For years, vulnerability research was a skill for a scant few. Scouring the bowels of the internet to find meaningful issues required significant human-led time, effort, and expertise. Even with automation, progress was bounded by how much a person or team could reasonably analyze.

With AI/large language models (LLM), that constraint is crumbling quickly. LLMs don’t replace deep expertise or intuition, but they don’t need to. The models’ main points of efficacy—and frankly, where they outpace humans—are pattern recognition, application of known bug classes, and connecting context across codebases. With these current capabilities, security vulnerability/issues discovery is less tradecraft and more search button.

Source: I.R.S. Records

I know. I get it. I took a research course in college during which we spent an entire month walking around Rush Rhees Library looking for references on Thomas Tallis. It was fantastic. I was the only one in my class that enjoyed it. Nonetheless, the class likely is—or should be—removed from the curriculum.

Security professionals who deal in vulnerability research have an entirely new charge in the current landscape. If the type of work doesn’t change, the human becomes obsolete.

Security and operations professionals must adapt. Almost by definition, volume becomes even more of a constraint in AI-led research programs. So, now what?

For already overworked and overloaded Ops teams, an increased volume of findings is not a benefit. With more issues landing in their queues (a portion of which are inevitably overlapping and valid due to automated and nearly-instantaneous analysis), findings are event harder to triage than before.

Instead of checking off false positives, teams are validating real issues right out of the gate.

This sounds like an improvement. Operationally, it isn’t. Teams are shifting from moving things out of the queue to moving things in. A backlog remains. A different skill set is required to handle the mountain of verified vulnerabilities.

In theory, we reduce staff burnout caused by the rote work of removing meaningless issues. We now need skilled professionals to oversee the successful stewardship of vulnerabilities.

Source: David Bowie.com

AI-assisted vulnerability research is being baked into a plethora of vendor products. These products’ aims aren’t only to remove the barriers of initial discovery, but to improve analysis, thereby focusing Ops teams’ time on triage of the highest priority vulnerabilities and issues.

The promise of these tools’ output is enriched context: how an application behaves at runtime, how controls interact, and whether an issue is realistically exploitable under current conditions.

More and more vulnerability management, exposure management, and risk management tools are also offering “verified fixes”—for these, closure is not only applied as part of the workflow, but the tool ensures fixes are effective and hold under stateful change.

AI and LLMs—”agentic” as it’s now ubiquitously called—proffer real promise here. And that’s what vendors are banking on. But the market is nascent and operators, rightly so, are reluctant to auto enforce. At least until a human, one with the requisite skill and judgement, can validate the findings.

A human-in-the-loop, of course, slows the process and progress of eliminating the vulnerability management backlog. Human attention has moved from identification to validation and prioritization, but the result is the same: failure to scale.

And until a product can produce, with a significantly high degree of certainty, that its proposed enforcement is accurate and reliable, skeptical security teams are going to insist that a human decide what matters and to how act on it.2

If something is “cooked” with vulnerability research, it’s not the research itself, or even the underlying AI/LLMs producing it; it’s how organizations are operationalizing it.

The front end of the research process can reliably be executed by AI models.

The middle of the process is also undergoing a transformation; a few commercially available tools (and likely a number of home-grown ones) can determine with a decent amount of accuracy which issues identified in a unique environment are exploitable, relevant, and require an urgent fix.

The tail end— auto-enforcing a control and proving remediation efficacy over time—is still a question mark.

Source: Amazon.com

As such, teams need to update their own models to mirror advances in tech. Though some are hesitant to do so, this is what the security industry was built for: tech innovation and application.

AI does not eliminate vulnerability research; it changes where human effort is essential. Finding vulnerabilities is not the hard part and no longer requires cloak-and-dagger skills. Continuing to optimize around that assumption is a sure bet to early retirement.

Teams must now embrace current capabilities and move to the middle-right of the process, where they can monitor and validate findings to track the model’s efficacy. Over time, as products become more accurate and reliable, the focus will shift even farther right, to enforcement and closure.

For the time being, we still need human intelligence to ensure AI accuracy.3 The practical shift is from detection to decision. Though tools are becoming better at analysis (environment-specific contextualization, prioritization, auto-closure), we’re not there yet. Any responsible SE will admit that behind closed doors.

With a human in the loop, the emphasis and time allocation move farther along the process, but not out of it. Not for the time being. The backlog of work remains, but it requires a keen eye toward the applicability of findings to the environments in which they’re found. It means allowing the model to execute the first few miles and focusing on the finish line—getting there without too many missteps.

This is not the end of vulnerability research, not by a long shot. It’s just not the same type of research the industry need five—or even two—years ago.