Vulnerability response in the AI-discovery era

What changes when AI can find vulnerabilities faster than teams can fix them, and a four-part plan for dealing with it.

Frontier AI models can now find vulnerabilities at a scale and speed humans can't match, with Mythos as the current high-water mark. That includes flaws with no CVE attached, in code that has been reviewed for decades. Access to the strongest models is restricted today, but the capability is spreading, and attackers get it too.

Here is the practical problem: finding vulnerabilities got fast and cheap. Triaging them, fixing them, and containing what gets exploited did not. If your program was already behind on its backlog, this makes it worse. So in this post, we’ll explore what actually changes, and how to build a program that keeps up.

Four shifts in the ground rules

1. There are more vulnerabilities than established institutions can process. CVE creation doesn't keep up with what AI can find, so some real findings will never have a CVE at all. Regardless of whether something has a CVE, if it represents a real business risk, your team owns doing something about it.

2. Exploits get faster and cheaper for attackers. The time from a vulnerability being known to it being exploited has collapsed. Mandiant's latest M-Trends report estimates the average time-to-exploit at negative seven days. This means that exploitation now begins before a patch exists. Your response and remediation times have to come down to match.

3. Risk acceptance gets harder to justify. There is an industry narrative that AI makes defense faster and cheaper, so leaving things unfixed looks less like a resource problem and more like a decision. Boards and auditors will expect security teams to operate faster and cheaper with AI, because attackers will.

4. Your whole attack surface is more exposed. Software, configuration, and identity weaknesses can all be discovered and probed at machine speed. This post focuses on software vulnerabilities, but the principles can be extended to other common attack vectors as well.

On a positive note: For any given codebase, this will be a surge and not an endless flood. Code is finite, and most AI-found flaws are known vulnerability classes with known fixes. The hard part isn't that the vulnerabilities are exotic, it's the volume of the vulnerabilities.

How to create a program for the new landscape: A four-part plan

Closing this gap is the security team's job. The same class of AI tools helping attackers is available to defenders. Use it — for triage, for routing fixes, and for response.

The plan outlined below will help you achieve this. Each part of the plan exists because the one before it isn't enough. You'll find more than you can triage, you'll triage more than you can fix, and you won't fix everything.

1. Scan and discover

For this first step, the goal is that everything found ends up in one place you can manage. CVE discovery is the straightforward part: Make sure every important asset is actually covered, whether that takes one very complete vendor or a combination of sources.

The new work is non-CVE findings. Your scanning needs to pull in vulnerability data beyond the CVE catalog, including AI-discovered flaws, and feed it into the same triage and remediation process as everything else. A tool that only manages CVEs is blind to this new class of findings. Luckily, the remediation and response patterns remain the same, as the non-CVE vulnerabilities are tied to what we know how to fix — libraries, binaries, and images.

2. Prioritize

Even before AI, only the most mature security and engineering orgs could fix everything. Now proper triage is even more critical. There may be SLA reasons to fix everything eventually, but from a security standpoint you need to know which vulnerabilities actually add business risk. There are three signals that really matter, with the first two only measurable live in the environment:

• In-use. Is the vulnerable package actually loaded into memory and running, or just installed somewhere?
• Exploitability. Can it be reached — through network access, exposure, or something else?
• Impact. If this asset is breached, is there any real negative business impact?

Two organizational points: 

1. Focus your team on the short list this analysis produces. 
2. Have confidence in the tools helping with the triage: Deprioritizing something is an active decision, and it only sticks if the team trusts the filter.

3. Remediate

Remediation can't be artisanal at this volume. Where to fix, who fixes it, and how it gets routed should be answered by automation, not by hunting through wikis.

• Fix at root. Patch the base image once instead of patching every instance built from it.
• Automate ownership and assignment so findings route to the right team without manual research.
• Use autoremediation where you can. Generated pull requests and config changes can increase how much fix work moves through the pipe.
• Block pre-production. If something doesn't need to reach live for a business reason, stop it at the admission controller or in the pipeline. That's the cheapest fix there is.
• Learn your other levers. Patches won't keep up with the rate of discovery, so know your cloud, network, and identity configurations well enough to use them as fixes. Cutting off network access to a vulnerable workload is remediation too, and it's often faster than waiting for a patch.

The organization also has to actually prioritize this work. How you get buy-in depends on your org, but it's part of the job, not an afterthought. Buy-in runs on business-driven metrics and goals, and gets a defense strategy prioritized from the board down to the engineering and infra teams making the fixes. A good question to focus on: How long do the vulnerabilities that matter stay exposed on the assets that matter?

4. Plan for vulnerabilities being exploited

You won't fix everything. Sometimes this is due to resources. Sometimes there's no fix available, or the fix breaks a pile of dependencies. For everything that stays exposed, the runtime is your safety net.

The good news is that post-exploit behavior looks similar no matter how novel the entry point: privilege escalation, recon, key retrieval. You don't have to recognize the exploit to catch the attacker — the window between exploit and business impact is where you can meaningfully protect your organization.

In practice:

• Watch workloads for indicators of compromise: data exfiltration, suspicious recon, and malware activity.
• Measure how fast you can detect and, more importantly, how fast you can respond, and find the bottlenecks: data not processed fast enough, people not looking fast enough, or too many things to look at. Each of these bottlenecks can be solved with tools or processes. Leverage AI agents if you have too many findings or you're lacking in off-hour coverage. Bring response closer to the data source if your data and enrichment pipelines are too slow.
• Build real containment playbooks. Decide up front what can be done autonomously and what needs a human. Define escalation paths.
• Set up a business notification process before your team ever needs to take a destructive action, not during the incident.
• If the volume or skill required is beyond your team, supplement it with a service provider or agentic SOC tooling.

Conclusion

None of this is novel. It's coverage, triage, an industrial fix pipeline, and a real plan for the things that get through. What’s changed is that AI has raised the stakes on both ends: attackers find more, faster, but defenders have the same tools available and must learn to leverage them effectively. Discovery scaled. Now the response has to match.

‍