By now, it is clear that AI and agents are fundamentally changing how modern software gets built, shipped, and secured, with development teams producing code at a volume and velocity that the traditional AppSec operating model was never designed to handle.
If we’re being honest, AppSec was already struggling to keep pace in the pre-AI era, with efforts such as “Shift Left” and DevSecOps largely falling short, producing noise for developers and bolstering the very silos between teams they meant to break down.
That said, the same capabilities driving the AI velocity are also industrializing vulnerability discovery, compressing exploitation timelines, and steadily marching toward autonomous exploitation, which means the gap between how fast software changes and how fast we secure it is widening in both directions at once.
In this article, I will walk through how AppSec and vulnerability management are evolving in the age of AI and agents, from growing vulnerability backlogs and exploitation’s rise as a leading attack vector to the industrialization of vulnerability discovery and what it demands of modern AppSec programs.
I will also take a look at how Gecko Security, a Resilient Cyber partner and prior guest on the show, is putting one of the more promising answers into practice, eliminating entire classes of vulnerabilities rather than playing whack-a-mole with individual findings.
So with all of that said, let’s begin to dive in.
Drowning in Backlogs
To level set, the vulnerability landscape was already straining defenders before AI entered the picture. FIRST’s vulnerability forecast projects roughly 59,000 new CVEs for 2026, the first year we will cross 50,000 published CVEs annually, while NIST moved approximately 29,000 backlogged CVEs into a “Not Scheduled” category, effectively conceding that the enrichment pipeline the entire ecosystem depends on cannot keep pace.
Now, as I argued in Why 70,000 CVE’s is Less Scary Than It Sounds in my discussion with FIRST’s Jerry Gamblin, raw CVE counts have always been a poor proxy for actual risk, given that only a small fraction of published vulnerabilities are ever exploited in the wild.
The problem is that organizational vulnerability backlogs do not care about that nuance. Large enterprises are sitting on backlogs in the hundreds of thousands of findings while remediating roughly 10% of them in a given month, and the inputs to those backlogs are accelerating, with GitHub hitting 1 billion commits in 2025 and pacing toward 14 billion in 2026, driven overwhelmingly by AI coding agents.
More code means more vulnerabilities, more findings, and more debt for AppSec teams that were already underwater.
The Exploitation Era
While the backlogs grow, attackers have gotten far more efficient at capitalizing on them. As I covered in The DBIR’s Exploitation Era, Verizon’s DBIR shows exploitation of vulnerabilities has become the leading initial access vector in breaches, nearly doubling the share held by phishing, a notable inversion of the attack hierarchy most defenders internalized over the past decade.
Meanwhile, only 26% of critical Known Exploited Vulnerabilities (KEVs) were fully remediated in 2025, down from 38% the year prior, with organizations taking a median of 43 days to remediate edge device vulnerabilities.
Time-to-exploit trends make those remediation timelines look even worse. As I laid out in The AI Cyber Capability Curve, the median time from disclosure to first observed exploitation has collapsed from 771 days in 2018 to 84 days in 2021 to roughly 6 days in 2023, and in 2026, 67.2% of exploited CVEs are zero-days, weaponized before or on the day of disclosure, up from 16.1% in 2018.
Attackers measure time-to-exploit in hours while defenders still measure remediation in weeks and months, that’s a fundamental mismatch and it isn’t in our favor.
CISA has taken notice. Its Vulnerability Review opens by pointing out that most compromises have not relied on advanced techniques but instead:
“Exploited simple, known software vulnerabilities that remain widespread and persistent in publicly exposed assets,” and that “Increasingly, cyber threat actors are using artificial intelligence (AI) to automate all the steps necessary to exploit these vulnerabilities.”
In fact, CISA explicitly states it is publishing the review “to establish a baseline of the vulnerability landscape prior to widespread AI-enabled vulnerability discovery.” When the nation’s cyber defense agency is planting a flag to measure the before-and-after of AI-enabled vulnerability discovery, that tells you something about where this is headed and it isn’t pretty.
Industrializing Discovery, Automating Exploitation
The direction is already visible in the research. Vulnerability discovery has been industrialized, and exploitation is being automated right behind it, as the next shoe to drop.
On the discovery side, frontier labs and researchers keep demonstrating capabilities that were considered aspirational just a couple of years ago. Anthropic has discovered 500+ high-severity zero-day vulnerabilities across open source codebases, including 22 Firefox vulnerabilities in a two-week span. Their Glasswing update showed that they had discovered 23,000+ vulnerabilities as of May.
DARPA’s AI Cyber Challenge drove the cost of AI-driven vulnerability discovery down to $152 per vulnerability across 54 million lines of code. This was further corroborated by the UK AI Security Institute’s evaluations, where frontier models completed expert-level offensive cyber tasks at rates that climb with every model generation, including multi-stage corporate network attack chains that take human experts roughly 20 hours.
The exploitation side is following the same curve. The researchers behind the MOAK agentic exploit workflow demonstrated autonomous exploitation of 174 of 178 known exploited vulnerabilities in testing, including going from a public React vulnerability to a working shell in 21 minutes with no human intervention.
Researcher Sean Heelan showed AI agents generating 40+ working exploits for a single flaw at a cost of around $50, while a swarm-based research effort surfaced 100+ exploitable Windows kernel driver vulnerabilities across AMD, Intel, NVIDIA, Dell, Lenovo, and IBM in 30 days for $600 in total compute, roughly $4 per bug.
The strain is even showing up in the disclosure ecosystem itself, with HackerOne’s Internet Bug Bounty pausing submissions in March 2026 as valid AI-generated vulnerability reports climbed 210%.
I have described this asymmetry before, and I will repeat it here because it captures the structural problem. Attackers need an API key and an afternoon, while defenders need a quarter and a steering committee.
Fully autonomous exploitation at scale is not quite here yet, but every data point above suggests we are approaching it, and the organizations planning for it now will be in a fundamentally different position than those waiting for proof.
Context Is the Scarce Resource
All of this has real implications for how AppSec and vulnerability management programs need to operate. For one, the legacy model of dumping low-context scanner output onto development teams and calling it risk management is finished. When findings volume grows faster than remediation capacity, the only lever left is ruthless prioritization, and that requires context that most AppSec tooling and teams have historically failed to provide.
CISA’s Vulnerability Review is blunt on this point, noting that:
CVSS scores “reflect theoretical severity, not real-world impact” and that “AI-enabled vulnerability discovery is rapidly increasing the volume of disclosed vulnerabilities, requiring ruthless patching prioritization.”
CISA’s prioritization guidance now hinges on four variables:
That is the same direction modern AppSec needs to move, leading with known exploitation, exploitability, reachability, and business context rather than raw severity scores.
A critical-severity finding in an internal tool with no path to sensitive data is not the same as a medium-severity finding sitting on an internet-facing asset with automated exploit tooling in the wild, and treating them the same is how teams end up drowning in backlogs while the vulnerabilities that matter sit unpatched.
This is a theme I have been discussing for years. The difference now is that AI has raised the stakes on both sides of the equation, and the teams that leverage AI and agents to bring exploitability and business context to their findings will fair far better, especially if they look to try and root out the causes of vulnerabilities as well, which takes me to my next point.
Eliminating Entire Classes of Vulnerabilities
That brings me to the second half of this discussion, which is what it looks like when someone actually builds for this reality.
Gecko Security is an AI AppSec company I recently hosted on the Resilient Cyber podcast in an episode titled Building an AI AppSec Engineer.
A couple of moments from that conversation have stuck with me since. Ryan called MTTR “a fake metric that makes teams look good,” arguing that recurrence rate is the metric AppSec should actually care about, since MTTR incentivizes closing repeated instances of the same flaw rather than addressing the root cause, and as I often say in cyber (and general), incentives drive behavior.
JJ made the point that as AI automates more of the discovery and triage work, “the scarce thing left is the judgment.”
Both of those observations converge on an idea that CISA has been advocating for years through Secure-by-Design, which urges software producers to “eliminate common vulnerability classes and publish roadmaps for the rest.”
It shows up again in CISA’s Secure-by-Demand guidance, where one of the key questions buyers are told to ask vendors is which vulnerability classes the producer has already eliminated and what the roadmap is for the rest, and in the Vulnerability Review’s discussion of AI-powered threats, CISA’s prescription for defenders explicitly includes “elimination of entire vulnerability classes” alongside MFA and engineering resilience into AI-integrated systems.
The Vulnerability Review data shows why this matters.
Across FY2024 and FY2025, 41.5% of KEVs map to what MITRE calls “stubborn weaknesses,” the 18 CWEs that appeared in the CWE Top 25 every single year from 2019 to 2025.
Per CISA, three of today’s top 10 CWEs would have been considered “unforgivable” by the standards MITRE published nearly two decades ago, and their persistence illustrates that “the problem is not technical complexity, it is organizational culture, developer workflows, and systemic gaps in Secure-by-Design adoption.” In other words, the industry keeps losing to the same classes of flaws, over and over, at scale, rather than to novel attacks.
Gecko’s own research, presented at Black Hat 2026 and detailed in their executive brief on eliminating vulnerability classes, quantifies just how much of the backlog problem is really a root cause problem.
By tracing every publicly disclosed vulnerability in n8n and GitLab back to its fixing commit, Gecko found that 569 disclosed findings traced back to just 105 distinct root causes, with 1,117 duplicate backports along the way.
For n8n, 67% of public disclosures were repeats of previously disclosed issues, and for GitLab the figure was 58%, with the repeats costing roughly $44,000 in bounties for n8n and over $1 million for GitLab. The longest-lived vulnerability class persisted 728 days before comprehensive remediation. As the research puts it:
“What looks like an unmanageable backlog is a short list of root causes. Fix the class once, at a shared point, and it stays fixed.”
That framing resonates with me because it converts an intractable-sounding problem, hundreds of thousands of findings and growing, into a tractable one, a bounded list of systemic flaws that can actually be burned down, if we intentionally focused on doing so.
It is also exactly the kind of work AI and agents are suited for, reasoning across an entire codebase to identify the shared root cause behind dozens of surface-level findings, something no human AppSec team has the cycles to do at scale.
The Cal.com Example
For a concrete look at what this means in practice, Gecko’s case study with Cal.com is worth a read.
Cal.com is a scheduling platform used by over 1 million people, with customers including Vercel, Coinbase, and Ramp, and it spent five years as an open source project before going closed source in April 2026.
Their situation reads like a compressed version of everything discussed above. After adopting AI coding tools, pull request volume jumped from roughly 40 to 100 per day, supported by a security team of two engineers covering 25 engineers, something many of us in AppSec can likely relate to.
They were running multiple scanners, both legacy and AI-native, which generated duplicated findings, inconsistent severity ratings, and a steady stream of false positives. Cal.com CEO Bailey Pumfleet captured the consistency problem well, noting that “If you ask two different AI agents to review the same PR, they’re going to pull out very different results.”, which isn’t surprising given the non-deterministic nature of AI.
Consolidating on Gecko gave them a single source of truth for pull request security decisions, with context-aware findings validated by proof-of-concept exploits, an understanding of production exploitability and data sensitivity, and findings automatically routed to code owners, with every PR scanned before human review.
Keith Williams, Cal.com’s Head of Engineering, described the outcome as “One tool that gives us great results from a full scanning perspective, and every single pull request that goes in, we know is protected.” His broader observation applies to every team shipping AI-assisted code right now, “This is the new reality. Especially with Mythos, you’re always going to find new stuff.”
His quote doesn’t even account for the fact that Mythos level capabilities are now becoming commoditized, with open weight models quickly catching up to the frontier and available to malicious actors everywhere.
Notice what that approach operationalizes:
Exploit validation instead of theoretical severity
Production context instead of isolated code findings
The elimination of recurring classes instead of an ever-growing queue of one-off tickets.
Those are precisely the properties I have argued modern vulnerability management needs, and precisely what CISA is pushing the ecosystem toward.
Closing Thoughts
This is far from an exhaustive discussion of how AI and agents are reshaping AppSec, and much of the trajectory remains to be seen, particularly around how quickly autonomous exploitation matures from research demonstrations into commodity tradecraft.
That said, the direction of travel is clear. Vulnerability discovery has been industrialized, exploitation timelines have collapsed, backlogs are compounding, and the traditional AppSec model of low-context findings and human-speed triage cannot survive contact with machine-speed offense.
Security has historically been a laggard when it comes to adopting transformative technology, hand-wringing over risks while the business races ahead.
AI and agents offer us a rare chance to break that pattern, using the same capabilities that are empowering attackers to finally address root causes, eliminate entire classes of vulnerabilities, and focus our scarce human judgment on the decisions that actually matter.
Will we take it, or will we spend the next decade remediating the same stubborn weaknesses we have been remediating for the last two?
The root cause math here only holds if the codebase converges on shared implementations you can point a fix at. That was true of n8n and GitLab's five years of human written history. It gets a lot shakier once 100 PRs a day come out of agents that don't reuse the same auth helper twice, you can end up with the same vulnerability class expressed five different ways with no common commit to trace back to. I saw a version of this at What Breaks recently with MLflow, the patch closed the specific reported path but left the exploit's underlying pattern sitting right next to it, still working five years later. The diligence question for a vendor selling root cause elimination is whether they catch a class showing up as independently written variations, not just literal duplicates and backports.
"an idea that CISA has been advocating for years through Secure-by-Design, which urges software producers to “eliminate common vulnerability classes and publish roadmaps for the rest.”
DUH. As I've been saying for at least twenty years.
AI-assisted design (by AI other than LLMs which are unreliable and insecure by definition) and deterministic-AI-generated code has always been the solution the industry will never do because it "offends" nerd programmers who think they're the cat's meow, despite being as unreliable and insecure as LLMs - as the LLM vulnerability discoveries are now proving.