LLMs are dual use, so use them

For the past month or so, I’ve been involved in several long-running conversations with vulnerability handlers and CVE policy types that all amount to a problem statement of, “ah jeez, we’re getting tons of vulnerability reports from AI, and it’s going to get out of hand here pretty quickly! What shall we do?”

Here’s what we do, we automate and make the whole business of vulnerability management smoother and easier for everyone involved, reporters of bugs and receivers of bugs alike.

We’ve known this for a while – pretty much the entire time I’ve been involved in vulnerability reporting. We’ve been watching the count of issued and reserved CVEs creep up, year over year, without exception. Here’s the last 10 years, according to CVEDetails.

The careful reader will note that for all of those years, we didn’t have MYTH🐙S breathing down our necks, and yet CVE disclosures have been marching up and to the right without fail for a decade. Now, the threat of AI-assisted vulnerability discovery is forcing the conversation for real with some pretty serious juicing of discovery and reporting rates.

I think we have a real shot here at modernizing vulnerability disclosure in general and CVE assignment in specific to keep up with the volume. Which is great, because who doesn’t love a new project? As a colleague in CVE-land once paraphrased, “let’s not let this crisis go to waste.” We’re actively working up some ideas and plans and schemes to imbue the whole CVE reservation-to-publication pipeline with some much-needed automation anyway; I know of at least three different CVE-connected working groups who are focusing on some variation of a “more, better, faster” goal for vulnerability disclosure. (The CNA Research Working Group has an open comment RFI available on this topic, right now, through June 5, 2026.)

One of the simplest things product owners can do is make it very easy and obvious on how to report vulnerabilities. Dropping a well-formatted, .well-known/security.txt file in the root of basically every website that talks about your software goes a long way toward pointing people (or agents) in the right direction and can help reduce misfired vulnerabilities landing in a public support queue.

Fight fire with fire #

In the meantime, we cannot leave our vulnerability handlers on the sidelines. Since we know that bug-hunters are using increasingly common tooling to uncover vulnerabilities and telling product owners about them, I’m sorry to say that the receivers of these reports need to get on the AI train as well. We cannot be triaging, verifying, and fixing these bugs at mere human speeds any more, because we simply cannot keep up. One of the things LLMs are pretty good at, and are marketed for, is the triage stage of basically any support ticket system.

Vulnerabilities don’t need to be any different. Hooking an LLM into your intake should be able to tell you, pretty quickly, if this is actually a novel bug report. We’re seeing today that one of the side effects of widely available tooling is that the tools are uncovering the same bugs, over and over again.

And of course, you needn’t leave all the prompting fun to the bug-hunters. In most cases, once you know about a technical bug, a technical fix is usually pretty straightforward; PSIRTs can and should be using LLMs to whip up quick fixes to address the immediate issue, and then subject their (often complicated, years-spanning) codebase to a thorough AI-assisted code review to spot similar issues that are lurking in other parts of the code. Just like with anything AI, the results aren’t going to be perfect, but LLMs are, in their cold, mathy hearts, excellent pattern-matchers. Springboarding a code review off of a vulnerability report is a great way to get some focused security review with a prompt along the lines of, “Find other instances of this reported bug that might have cropped up in similar functions across this repository, and let me know if you find anything suspicious.” (By the way, don’t fall into desperation prompting traps like “and make no mistakes.” LLMs are probabilistic, not exactly mechanistic.)

Bug bounty value adds #

Here’s a pro-tip for the bug bounty hunters of the world. Now that you know your AI-augmented tooling is likely to produce duplicate bug reports, you can make sure that your report floats to the top of the queue by using your mighty AI sidekick to sketch out a fix, as well as the initial attack. Even better, you could provide some indicators of compromise (IOCs) and other fingerprints describing how people can tell if your new bug is ever actually exploited in the wild. That way, even if it is a duplicate, your report is instantly more valuable than the last one, because it comes with some actually helpful pointers for the product owners.

Of course, you should also, ya know, actually do the work involved in bug hunting. Validate that your finding is actually real, has some articulable attacker value, and doesn’t require some wonky preconditions (or if it does, be clear about those). LLMs are still prone to hallucinations and wishful thinking, so it’s on you to validate the findings before firing them off.

I believe this kind of thoughtful, end-to-end reporting will separate the noise-producers from the truly helpful, and thus, the folks that do this for money should see more rewards for their work with just a little extra packaging.

I understand that fixing bugs isn’t your bag, oh noble vuln-spotters. But, this brief window of unique AI-assisted productivity on the findings side is going to further reduce your research product to mere commodity status. You’re going to need to come up with ways to make sure that your bug report is the most useful among dozens to hundreds, and I bet that packaging up some IOCs and patches will make yours stand out.