Defenders and threat actors got handed the same superpower this year. It finds vulnerabilities.
The CVE curve is the cleanest public proof we have. 48,185 published in 2025, up 21% over 2024, and 2026 is running far hotter. CVE publication held near 51 a month for nearly four years, then broke. A changepoint analysis lands the break at November 2025, and after it the slope jumps about 11x, from +51 CVEs a month to +570. That is not a curve anymore. It is a wall.
CVEs are the coordinated-disclosure record, the good guys showing their work. But the capability behind that spike is not exclusive to the good guys. The same model that finds bugs for a maintainer finds them for an attacker. What the CVE curve measures is the visible edge of a finding capability that is now cheap, fast, and in everyone’s hands.
This is a capability, not a headcount
You could read the spike as more organizations pitching in. It isn’t. I pulled the full CVE record set and counted distinct active CNAs, the authorities that publish records, per month. Their count roughly doubled since 2022, from about 94 a month to about 177. So more publishers, sure. But the mean output per publisher climbed from around 22 to over 33, while the median stayed flat at four to five the entire time.
When the mean climbs and the median doesn’t, the typical publisher hasn’t changed. A few publishers got dramatically more productive. That is the signature of a capability, not a hiring spree, and it lands exactly where you’d expect. Credit to Jerry Gamblin at RogoLabs, whose CNA data makes this decomposition possible.
GitHub sat near 6% of all CVEs for years, then published 35% more records in 2025 while the whole program grew 21%, on the back of LLM-assisted triage. And Anthropic’s Frontier Red Team ran Claude Opus 4.6 across open-source code and surfaced over 500 high-severity vulnerabilities in a pass, then found 22 in Firefox in two weeks, a fifth of all the high-severity Firefox bugs fixed in 2025. These are defenders publishing. An attacker running the same models does not file a CVE. They just have the bug.
And the defenders who do publish are holding the line down on purpose. Anthropic ships its findings into the CVE pipeline through coordinated disclosure, and its policy is explicit that it will not dump large volumes of findings on a single maintainer without first agreeing on a pace that maintainer can absorb. So the steepest curve in public security data is being actively throttled by the people producing it. The chart above is not the finding rate. It is the finding rate after the responsible finders slowed themselves down so maintainers could keep up. The real slope is steeper than what you can see, and the attackers filing nothing are not throttling at all.
You cannot answer exponential finding with linear fixing
Here is the asymmetry that should keep you up. Finding scaled. Fixing didn’t.
Most security programs still run fixing as a process that sits beside development. Scanner finds something, files a ticket, ticket enters a queue, queue waits on a human, human context-switches back into code they wrote weeks ago. That worked when findings arrived at a human pace. It falls apart the moment the finding side goes exponential, because every automated finder that comes online adds to the pile without adding a single unit of remediation capacity.
You do not close that gap by triaging harder. You close it by finding and fixing at the same rate the threat operates, and the only place that is possible is inside the development workflow itself. Security that lives outside the loop, in its own tool, its own queue, its own dashboard, loses to a threat that scales. A separate security queue does not fix the backlog, it doubles it. The answer to a queue problem is not a nicer view of the queue.
Why agentic-only finding and fixing won’t be your workflow
The obvious move is to point a frontier model at your codebase and let it rip. It will find things. But as your everyday development gate, agentic finding has problems that get worse at scale, not better.
It is expensive. Anthropic spent $4,000 in API credits just trying to write exploits for the Firefox bugs, and succeeded twice. Running a probabilistic finder against every branch, every PR, every day is a token inferno that grows with your velocity.
It is slow and uneven. It is probabilistic by design, which is why it finds novel bugs and also why it is not repeatable. Run the sweep again, get a different set. That is a fine property for research and a terrible one for a merge gate that has to give the same answer twice.
And it degrades into noise. An agent that files findings into a queue is just a faster way to generate “here’s a PR for you to review,” and we already know where those go. Nobody. You have seen the graveyard of unreviewed bot PRs. Agentic finding without a workflow to absorb it makes that graveyard bigger.
Now follow that thread into fixing, because this is where it really breaks. Say you run agentic finding out of band anyway. Every finding it produces needs a fix, and if the fix also happens out of band, you have rebuilt the exact problem: a second queue of machine-generated pull requests waiting on a human who is already underwater. Agentic finding feeding agentic fixing feeding a review queue is not a loop, it is two firehoses pointed at the same overloaded person. You did not close the gap between finding and fixing. You automated both ends of it and left the bottleneck in the middle exactly where it was.
The only way that out-of-band model actually works is to close the loop with no human in it, find, patch, verify, and merge autonomously. That is real, and a handful of teams are doing it. But it takes a dark software factory: full test coverage you trust enough to gate merges on, deterministic verification wired into the pipeline, rollback and provenance for everything the machine ships, and the staff to build and babysit all of it. If you are Google or a frontier lab, you can run that. Almost nobody else can, and betting your security posture on infrastructure you do not have is not a plan.
We will make the full efficiency case another day. The point for now: probabilistic finding is a powerful supplement and a poor foundation, and probabilistic fixing bolted on beside your workflow just doubles the queue. Your daily gate needs to be fast, repeatable, cheap enough to run on every change, and built into the workflow instead of stacked beside it.
Deterministic verification and oversight: what you can prove today
This is where deterministic finding earns its keep, and where oversight stops being a nice-to-have.
Deterministic finding and verification. A deterministic runtime test finds the same real vulnerabilities every run and does not hallucinate. Run it inside the workflow, not beside it: as you and an agent work a problem together, the security check happens naturally as part of solving it, at machine speed and predictable cost, with the PR as the double-check instead of the first time anyone looks. When a model or a developer proposes a fix, deterministic verification proves the vulnerability is actually gone and nothing else broke. That proof cannot come from another model. A probabilistic system grading probabilistic work is a vibe, not a verification. Anthropic said as much in the Firefox writeup, recommending task verifiers that let an agent confirm a fix truly closed the hole. The frontier lab is asking for the deterministic check. That is the thing.
Oversight and provenance. Turn a swarm of agents loose on finding and fixing and you get velocity with no memory. What was found, what was fixed, what was verified, who did it, and can you prove any of it to an auditor or an incident responder six months from now? An agentic free-for-all has none of that. It is throughput without a record. Oversight and provenance, a central, trustworthy account of every finding through its fix and verification, is not a prediction about the future. It is something you need the day you let automation into the loop, and it is something we deliver now.
Build security into the developer workflow
Put it together. The threat found an exponential gear. The public CVE curve is the receipt, and it is the polite floor, not the ceiling. You answer exponential finding by finding and fixing at the same rate, which only works inside the development workflow, not in a queue beside it.
That loop needs a shape: deterministic finding fast and cheap enough to run on every change, the model or the developer to propose the fix, deterministic verification to prove it landed, and oversight and provenance across all of it so you can trust and account for what the automation did. Probabilistic finding rides on top for reach and novelty, where its cost and variance are an asset instead of a liability.
That is the work at StackHawk. Not a better inbox for an exponential problem. Finding and fixing built into the workflow, with the deterministic backbone and the central oversight that let you run at machine speed without flying blind. The finders went exponential. Your fixing has to live where the code does. if you want to try finding and fixing as part of the dev workflow, give Wingman a try for 14 days, free.
