For as long as vulnerability management has existed, the defender has been behind. Attackers — or more often, vulnerability brokers and researchers with an incentive to stay quiet — know about a flaw before you do. Your patch cycle starts when the disclosure lands, which is to say, after the adversary has had a head start measured in weeks or months.
In July 2025 that inversion happened for the first time in a documented, real-world case.
Big Sleep and CVE-2025-6965
Google's Big Sleep agent, developed by Google DeepMind and Google Project Zero, identified a critical vulnerability in SQLite that was known only to threat actors and was about to be exploited. Google Threat Intelligence Group's telemetry showed the adversary preparing; Big Sleep found the flaw; the defect was reported and fixed before it could be used.
Google's own framing is careful and worth quoting precisely: they believe this was the first time an AI agent had been used to directly foil efforts to exploit a vulnerability in the wild. The pattern is the interesting part — threat intelligence identified that an attack was imminent, and the agent was pointed at the target software to find what the attackers had found.
Defensive AI did not win by being cleverer than the attacker. It won by being pointed at the right code, at the right moment, because someone knew a campaign was coming.
That is the same logic as pre-emptive defence generally: the leverage comes from knowing where to look before the incident tells you.
What DARPA's AI Cyber Challenge actually proved
Big Sleep is one agent, one case. The DARPA AI Cyber Challenge (AIxCC) is the systematic evidence, and the numbers are worth sitting with.
Across 54 million lines of code in the final competition:
- Competitors' cyber reasoning systems discovered 54 unique synthetic vulnerabilities across 63 challenges, and patched 43 of them.
- They identified 86% of the synthetic vulnerabilities, up from 37% at the semifinals, and patched 68% of those identified, up from 25%.
- They also found 18 real, non-synthetic vulnerabilities in production open-source software, responsibly disclosed to maintainers.
- Average time to submit a patch: 45 minutes.
- Average cost per competition task: about $152 — against bug bounties that range from hundreds to hundreds of thousands of dollars.
- Every one of the seven finalist teams found a real-world vulnerability.
Team Atlanta won, with Trail of Bits second and Theori third. Four of the seven systems were released as open source immediately. Anthropic, Google and OpenAI each donated $350,000 in model credits.
Read those numbers as an economist rather than a security engineer, and the implication is stark. The marginal cost of finding a vulnerability has fallen by orders of magnitude, and the marginal cost of patching one — in human review, regression risk and change management — has not.
The asymmetry nobody prices correctly
Here is the uncomfortable symmetry. The same capability is available to both sides. Nothing in AIxCC is defensive by nature; a cyber reasoning system that can find and patch a flaw in 45 minutes is a system that can find and weaponise one.
What differs is the cost of acting. For the attacker, every vulnerability found is optional upside. For the defender, every vulnerability found is a mandatory cost: triage, patch, test, deploy, and the risk that the patch breaks something more important than the flaw. Attackers choose their moment. Defenders absorb the queue.
Which means the defender's problem is not discovery. It is prioritisation under a flood. If machines can now surface thousands of genuine flaws in your estate, a CVSS-ordered remediation list is not a plan; it is a shrug with a spreadsheet attached.
What actually changes in practice
Three shifts, in order of how soon they will bite.
1. Patch speed stops being a virtue and becomes a floor
If the window between disclosure and exploitation is measured in hours, then “we patch critical within 30 days” is a policy written for a threat that no longer exists. The organisations that survive this transition will have automated remediation for the well-understood classes and pre-authorised change processes for the rest.
2. Triage becomes the scarce skill
The question stops being “what is severe?” and becomes “what is being targeted, by whom, and does it touch our estate?” That requires joining vulnerability data to threat intelligence about adversarial intent — which is exactly what an attack surface module mapping external threats to known internal vulnerabilities is for.
3. Your software supply chain becomes the main event
AIxCC targeted open-source software deliberately, because that is what critical infrastructure runs on. Most organisations cannot patch what they did not write, cannot see what their suppliers bundled, and have no inventory of either. Foundational flaws in widely used libraries are not one organisation's problem; they are everyone's, simultaneously.
The board conversation
The honest summary for a board is this: the discovery advantage that attackers held for thirty years is closing, but it is closing on both sides at once, and the defender carries a structural cost disadvantage in acting on what is found.
So the strategic question is not “are we using AI in security?”. Most organisations are, somewhere, in something. The question is whether you have changed your operating model to match a world where vulnerability discovery is cheap, abundant and continuous — or whether you have added a tool to a process designed for scarcity.
Blueridge advises boards and security leadership across the GCC on vulnerability prioritisation, threat-informed defence and the operating model changes that follow. If your patch backlog is growing while your headcount is flat, that is the conversation.
Written by the Blueridge team. If this is close to a problem you are working on, we are happy to talk it through.
Start a conversation