Triage at Machine Speed
A look at the Vulnpocalypse, AI’s industrialization of vulnerability discovery, and why agentic triage may be how defenders finally keep pace
Across a 20+ year cybersecurity career, much of my time has been spent in Vulnerability Management and AppSec across DoD, federal civilian, and enterprise commercial environments, and eventually writing Effective Vulnerability Management.
In all that time, the fundamental challenge has stayed remarkably consistent. Too many findings, too little context, and not nearly enough capacity to remediate.
The past 18 months have changed the math.
AI has industrialized vulnerability discovery, and increasingly exploitation, something I dug into in "Vulnpocalypse: AI, Open Source, and the Race to Remediate." Below, I walk through where the numbers stand, why legacy triage cannot survive contact with this reality, and how Resilient Cyber's partner, Maze, is applying AI agents to the problem.
The Numbers Behind the Vulnpocalypse
Start with data rather than vendor hysteria. FIRST's Mid-Year Vulnerability Forecast, published in June 2026, now projects roughly 66,000 CVEs for the year, up from the February median of 59,427, and actual volume has run 46.3% above that February forecast through April.
The drivers matter as much as the total, a 449% year-over-year jump in GitHub Security Advisory volume and a 164% spike in Q1 Mozilla CNA disclosures directly attributable to AI-assisted tooling.
As FIRST’s Éireann Leverett put it,
“We’re witnessing a major shift in the vulnerability landscape, not because software is suddenly less secure, but because our collective ability to find flaws has been structurally transformed.”
I discussed this dynamic at length with Jerry Gamblin in a recent conversation I wrote up in “Why 70,000 CVE’s is Less Scary Than It Sounds“.
GitHub alone now publishes one in five CVEs, and much of the surge is 25 years of accumulated human debt finally getting found, not a sudden collapse in software quality. Filter the flood through exploitation-focused lenses like CISA's KEV catalog and EPSS and the genuinely exploitable slice has stayed essentially flat. Jerry captured the situation in the FIRST forecast better than I could, writing that
“In 2026, the rain doesn’t stop. The job is no longer counting the drops. It’s knowing which ones will overrun the levee.”
Discovery, Industrialized
The count is only half the story. The same AI capabilities inflating disclosure volume are compressing the time between disclosure and exploitation. AISLE identified all 12 OpenSSL CVEs disclosed in January 2026, and Anthropic reported Claude discovered over 500 high-severity zero-days, including 22 in Firefox.
As Anthropic's Nicholas Carlini put it,
"Current models are already better vulnerability researchers than I am, and in a year, they will likely be better than everyone."
The exploitation side is just as sobering. Sergej Epp's Zero Day Clock found the median time from disclosure to first observed exploit was 771 days in 2018, fell to 6 days by 2023, and is now measured in hours, with 67% of exploited CVEs in 2026 being zero-days, up from 16% in 2018.
As Thomas Ptacek argued, high-impact vulnerability research will soon happen simply by pointing an agent at a source tree and typing "find me zero days."
There’s absolutely no question now for those of us on the defensive side whether AI can find the bugs, we know it can. However, what we’re still figuring out is if we can find, prioritize, and fix what matters in our own environments before attackers exploit it, and right now the evidence suggests we’re losing that race.
Backlogs, Toil, and Throwing It Over the Fence
None of this is landing on organizations with clean programs and manageable backlogs.
Long before AI, organizations admitted to remediating less than 50% of their vulnerabilities, while attackers weaponized flaws in 19.5 days on average against a defender mean-time-to-remediate of 30.6 days, per Qualys.
Yet of the 25,000+ CVEs published in 2022, less than 1% were actually exploited. That asymmetry, an ocean of findings and a puddle of exploitation, has always been the central prioritization problem in our field, now playing out at even greater scale.
The way the industry has historically handled this gap is something I wrote about in “Security Throwing Toil Over the Fence“.
Teams run their scanners, export thousands of context-free findings, and toss them over the fence to developers prioritized by little more than CVSS severity, something the stewards of CVSS themselves recommend against.
Developers wrestle with spreadsheets full of trivial, unreachable, or non-exploitable vulnerabilities, resentment builds between Development and Security, and the actual exploitable risk sits untouched in the noise. When everything is a priority, nothing is.
To be fair, the industry has made real progress. KEV, EPSS, reachability analysis, and threat intelligence are meaningful improvements over raw CVSS burn-down lists, and I have advocated for all of them. That said, they share a common limitation, they are global signals.
KEV tells you a vulnerability has been exploited somewhere and EPSS tells you the probability it will be exploited in the wild generally, but neither tells you whether it is exploitable in your environment, on your asset, with your configuration, compensating controls, and exposure. Exploitability is ultimately environmental, and that context has historically been too labor-intensive to gather at scale, since it required an experienced engineer to investigate each finding by hand.
That capacity constraint is the crux.
Human-speed triage was already failing at 25,000 CVEs a year. It has no chance at 66,000+ in environments where scanners generate findings in the millions and developers ship more code faster than ever.
AI as a Force Multiplier for Defenders
This is why I have argued, including at the SANS AI Cybersecurity Summit earlier this year, that security needs to stop hand-wringing about AI and start wielding it as a force multiplier. Attackers are not waiting on our AI governance committees. If AI has industrialized discovery and exploitation, defenders have to industrialize investigation, triage, and remediation by applying the same agentic capabilities to our side.
For leaders asking whether to build this in-house, the answer is more nuanced than a weekend prototype suggests. As Maze’s Co-Founder and CTO Santiago Castiñeira laid out in a candid talk on build versus buy, a prototype script is easy, but scaling it into a maintainable, audit-proof system with rigorous evals rather than “vibe checks” is a massive undertaking, with hidden costs around LLM inference at scale most security teams have never had to reason about.
Whether organizations build, buy, or blend, the destination is the same. We need triage that runs at the speed and scale of the discovery pipeline now flooding us, while applying the environmental context that global scoring systems structurally cannot.
A Look at Maze’s Agentic Triage
This brings me to Resilient Cyber’s partner Maze, who I recently spent time with for a full platform demo, and who I think represents one of the better examples I have seen of the force multiplier vision actually implemented on the triage front.
The core of the Maze platform is what they call Agentic Triage.
Rather than performing yet another scan, Maze can both conduct scans and ingests findings from the native scanners organizations already run, tools such as AWS Inspector or Wiz, and then turns AI agents loose to investigate each finding the way an experienced security engineer would, checking versions, tracing attack paths, examining the surrounding environment, and rendering a judgment on actual exploitability with the evidence to back it up. Additionally, Maze allows for the unified context from both cloud and code findings and telemetry, which often is siloed between separate tooling.
Their agents make the call based on that evidence rather than static rules, and the platform has been trained on millions of real investigations with multiple layers of validation, because as their team puts it, the agents are trained to never guess at the answer.
The impact of doing this well is significant. Maze estimates that 65% to 85% of cloud findings are not exploitable due to the specific environmental configurations they sit in, which tracks with what most practitioners feel but can never prove at scale, and which echoes the sub-1% exploitation figures I cited above.
What stood out to me in the demo was the depth of the environmental reasoning. In one example, a critical severity finding from a popular scanner was investigated by Maze’s agents, who determined the vulnerability was not exploitable because the affected component, a New Relic observability agent, did not process XML in that environment and the schema files required to trigger the flaw were absent entirely.
In another, a denial-of-service vulnerability was lowered from high to low because the pod had no network exposure, exploitation would require a custom exploit, and the pod was configured to automatically respawn, mitigating the impact even if it were somehow triggered.
Critically, this context cuts both ways, and this is where I think the approach differentiates itself from purely deprioritization-focused tooling.
In a third example, a finding rated medium by the scanner was elevated to critical because the agents determined the asset’s SQS APIs were exposed in a way that allowed an attacker to supply malicious XML, trigger the flaw, access secrets, and ultimately gain control of the file system.
A rules-based system keyed off CVSS, KEV, or EPSS would have left that finding buried in the middle of the backlog. This is the point I think many overlook when discussing vulnerability management at a high level, exploitability is environmental, unique to each organization and each system, and a triage approach that actually interrogates the environment will make calls in both directions that global signals structurally cannot.
Maze also enables organizations to rescore findings not just based on broader vulnerability intelligence sources such as the ones I mentioned above, but also environment context, using impact and likelihood. This takes findings from being generic and with broad generic, to making them scored specifically based on an organizations unique risks and environment.
Cloud to Code Coverage
Another aspect I want to highlight is the coverage across the stack, because most organizations experience vulnerability management as a set of disconnected silos, with cloud findings living in a CNAPP, dependency findings in an SCA tool, code findings in SAST, and no shared context between them. Security then throws each silo’s outputs over the fence separately, and Developers get to deduplicate the mess themselves.
Maze approaches this as one investigation across code and cloud.
In the demo, the platform mapped GitHub repositories to the AWS ECR images built from them and on to the running containers, providing a genuine code-to-cloud view that also enables deduplication of overlapping findings from sources like Dependabot and Wiz.
Their recently launched Maze Code extends the same agentic model into AppSec territory, spanning both dependencies (AI-SCA) and custom code (AI-SAST). On the dependency side, their agents trace the full call chain however many hops deep the vulnerability sits, including through the dynamic calls that traditional reachability parsers give up on, and then check the runtime and cloud environment to determine whether that path is actually exploitable rather than merely reachable.
That distinction matters, and it is the same gap I called out earlier with reachability-only approaches, an attacker being able to reach vulnerable code is not the same as an attacker being able to control the payload and realistically trigger the flaw in that specific environment.
The cross-enrichment flows in both directions, code context enriches cloud findings and cloud context enriches code findings, which is what makes the exploitability determinations credible in the first place.
The launch announcement from Co-Founder and CEO Harry Wetherald opens with a framing I appreciated, noting that AI is supposed to be reinventing application security and that so far we have seen more hype than impact, a sentiment I share about much of the AI security market. Industry analyst James Berthoty of Latio, whose tooling analysis I respect, stated “Maze uses AI agents with full context, which is why it delivers some of the most meaningful findings and fixes I’ve seen”, and his full analyst review of the platform is worth a watch.
The demo also showed their deeper business logic analysis, where agents identified a flaw in an open source e-commerce repository allowing an attacker to abuse the guest checkout flow to gain full account control, exactly the class of contextual vulnerability that pattern-matching SAST tools have historically missed and that has traditionally required a pentest to surface.
Integrations, Workflows, and Compensating Controls
For the practitioners wondering about the operational lift, the deployment model is refreshingly light.
Maze connects to AWS and Azure environments through a read-only IAM role, pulling runtime context via API with no agents to deploy, and GCP support is expected in the next few months. On the workflow side, the platform is designed to disappear into the processes organizations already run, pushing verdicts back into the originating scanners, closing findings automatically, or generating tickets in systems like Jira based on SLAs and automation rules the organization defines.
Remediation guidance both asset-centric and finding-centric, using GitHub and AWS activity trends to identify actual owners and bundling fixes so an engineer can resolve multiple vulnerabilities with a single change, and it can even be output as ready-to-run prompts for coding agents such as Cursor or Claude, meeting Developers where they increasingly work, and leveraging AI for AppSec, which I thought was neat.
Two other capabilities from the demo are worth calling out.
The first is compliance, where the same context-aware evidence trail that justifies triage decisions is being used by customers to support assessments against frameworks including generating deviation reports from a non-production replica of their environment, an approach that saves significant time compared to the manual evidence-gathering most GRC teams still suffer through. This is something I have written about in-depth in a piece titled “GRC is Ripe for a Revolution”.
The second is the movement toward compensating controls, where Maze is integrating with infrastructure like Cloudflare and using Web Application Firewall (WAF) data to further refine exploitability analysis. I find this direction particularly promising, because mature vulnerability management has never been only about patching.
As I emphasized in Effective Vulnerability Management, remediation is one path among several, and a triage system that understands when a WAF rule, network policy, or configuration change already mitigates a finding, or could, is reasoning about risk the way real security teams do, rather than treating the patch backlog as the only lever.
Closing Thoughts
This is far from an exhaustive discussion of either the Vulnpocalypse or the platform, and for those who want to go deeper I would recommend Maze’s Introducing Maze Code walkthrough and their Cloud Security Podcast conversation on bridging cloud and code security.
The bigger picture, though, is that the industry is on pace for roughly 66,000 CVEs this year, discovery has been structurally transformed by AI, exploitation windows are measured in hours, and organizations were already unable to remediate half of what they found when the numbers were a fraction of this size.
Human-speed triage is not going to close that gap, and neither is throwing ever-larger piles of context-free findings over the fence to Developers who are already drowning. We have a finite window to apply AI as a force multiplier on the defensive side of this race, and agentic triage grounded in real environmental context, of the kind Maze is building across cloud and code, is a strong exampl of what that looks like in practice.
The rain isn’t going to stop, as as FIRST has argued, the key is knowing which drops are worth addressing so the levee doesn’t overrun.