{"id":23900,"date":"2026-09-10T12:10:39","date_gmt":"2026-09-10T12:10:39","guid":{"rendered":"https:\/\/scannn.com\/the-left-in-shift-left-moved\/"},"modified":"2026-09-10T12:10:39","modified_gmt":"2026-09-10T12:10:39","slug":"the-left-in-shift-left-moved","status":"publish","type":"post","link":"https:\/\/scannn.com\/lv\/the-left-in-shift-left-moved\/","title":{"rendered":"The \u201cLeft\u201d in Shift-Left Moved"},"content":{"rendered":"\n
\n

For anyone who follows Resilient Cyber, you already know I\u2019ve been heavily discussing and highlighting the impacts AI is having on the economics of finding vulnerabilities. From frontier labs, startups, and independent researchers all surfacing flaws in mature codebases at a surging rate that the institutional ecosystem of disclosure, triage and patching was never built to absorb.<\/p>\n

I\u2019ve written about the discovery side of this in detail, including in a recent piece titled \u201c<\/span>AppSec in the Age of Agents<\/a><\/strong>\u201d, where I advocated for eliminating entire classes of vulnerabilities rather than grinding through them one ticket at a time, and worse, repeatedly remediating the same class of vulnerabilities over and over. <\/span><\/p>\n

However, there is also a second shift underway that gets a lot less attention than the whole \u201cVulnpocalypse\u201d narrative, and it is one I want to focus on in this piece. <\/p>\n

That is the place where code gets written and how it\u2019s moved. Now, it is often a coding agent running on a development endpoint, with a shell, package manager, credentials and the ability to take actions on its own, and most AppSec programs have no actual control point here at all. <\/p>\n

At the same time, remediation is being handed to agents too, which raises questions around concepts such as Human-in-the-Loop (HITL), which I\u2019ve already argued was largely a talking point, in a prior piece titled \u201c<\/span>The Human-in-the-Loop Illusion<\/a><\/strong>\u201d. Having agents both creating code and remediating flaws brings good questions, such as what HITL means when both the code and fix are machine-generated. <\/span><\/p>\n

In this article, I will walk through both sides of the shift, what they mean for AppSec practitioners and leaders and also use a recent demo and walkthrough I had with the team at Legit Security, a Resilient Cyber partner, as a practical example of how one team is building for this.<\/p>\n

So, let\u2019s unpack this often overlooked topic at the intersection of AI and AppSec.<\/p>\n

The first thing we need to acknowledge is that vulnerability discovery has went industrial in the first half of 2026. Per Vulnerability Research Jerry Gamblin\u2019s mid-year check in, 35,364 CVE\u2019s were published between January 1st and June 30th, a 49.5% increase over the first half of 2025, or one new CVE entry every 7.4 minutes. <\/p>\n

\n
<\/p>\n
<\/picture><\/div>\n

<\/a><\/figure>\n<\/div>\n

His full year projection at the time landed between 71,314 and 72,008, up from 48,185 <\/span>in <\/a><\/strong>all<\/a><\/strong><\/em> of 2025<\/a><\/strong>. FIRST provided their own forecast, which had to be adjusted midyear, showing roughly 66,000 potential CVE\u2019s for the year, from a February baseline of 59,427. In that update, they argued finding isn\u2019t the problem at all.<\/span><\/p>\n

\n

\u201cThe challenge for defenders is no longer the discovery of vulnerabilities; it\u2019s the capacity to verify, coordinate and prioritize them at scale.<\/strong><\/p>\n<\/blockquote>\n

Then we have the impact of the frontier labs on the space. <\/p>\n

Anthropic\u2019s Project Glasswing update put some large figures in the mix. Across it\u2019s partners, it had surfaced more than ten thousand high or critical severity vulnerabilities, and in open source projects specifically it had identified 6,202 high or critical findings, of which 90.6% of the 1,752 assessed so far proved to be valid true positives. Some partners told Anthropic their rate of finding bugs had increased by more than 10x, and a few asked the lab to slow down disclosures due to needing additional time to design patches. <\/p>\n

\n
<\/p>\n
\"\"<\/picture><\/div>\n

<\/a><\/figure>\n<\/div>\n

There\u2019s also OpenAI\u2019s <\/span>Patch the Planet<\/a><\/strong> effort, involve 55 critical open source codebases, which at the time of my writing have found 1,535 issues, with over 1,000 still awaiting a patch.<\/span><\/p>\n

\n
<\/p>\n
\"\"<\/picture><\/div>\n

<\/a><\/figure>\n<\/div>\n

When I spoke to longtime industry leader Casey Ellis on my show in July, he framed it as AI having collapsed the cost of finding and reporting vulnerabilities at the same time, with signal and noise both up roughly 10x, and the delta between the two getting wider. <\/p>\n

His line that I often reference is:<\/p>\n

\n

\u201dThe Vulnpocalypse was already here, it just sort wasn\u2019t evenly distributed\u201d.<\/strong><\/p>\n<\/blockquote>\n

This reframes the situation as an acceleration of a backlog problem we already had rather than a new novel threat. We are seeing the intake side of the ecosystem buckle in real-time, with cURL <\/span>temporarily pausing<\/a><\/strong> its bug bounty program after its confirmation rate fell from roughly 15% to 5% in 2025 (which has now improved due to a surge of high quality AI-driven reporting), and HackerOne\u2019s Internet Bug Bounty <\/span>pausing new submissions<\/a><\/strong> in March. NIST <\/span>reported <\/a><\/strong>that CVE submissions grew from 263% between 2020-2025, and moved most CVE\u2019s to a \u201cnot scheduled for immediate enrichment\u201d tier. <\/span><\/p>\n

With all of that said, Jerry made a point on my show that while the volume curve may have gone vertical, exploitation has not, and still sits flat at around 1-2%. At the time of our conversation only 85 of the CVE\u2019s published in the first half of 2026, or 0.24%, hand landed in CISA\u2019s KEV catalog as of his write-up, which is why FIRST framed it as a \u201crain versus flood\u201d\u201d, meaning practitioners need to not worry about raw finding counts and instead identify what they truly need to remediate. <\/p>\n

However, it is admittedly tough for a security program to determine that when new vulnerabilities are hitting them at machine-speed, so they are likely to drown either way, given they need to try and do their best to filter the surge. <\/p>\n

So, we\u2019ve discussed the AI-driven machine speed impact on discovery but what about remediation? <\/p>\n

That\u2019s the uncomfortable piece of the discussion for most. If you look at both Anthropic\u2019s Glasswing, and OpenAI\u2019s Patch the Planet, both efforts highlight 2\/3 or more of the vulnerabilities are yet to have been patched, even when verified as true vulnerabilities. Anthropic spoke to this directly, stating:<\/p>\n

\n

\u201dThe relative ease of finding vulnerabilities compared with the difficulty of fixing them amounts to a major challenge for cybersecurity\u201d.<\/strong> <\/span><\/p>\n<\/blockquote>\n

That\u2019s essentially a frontier lab describing the exact bottleneck we as practitioners have already lived with for years, but being exacerbated by AI. Cyentia\u2019s research found the typical organization has the capacity to remediate 1\/10 vulnerabilities in a given month, and that was <\/span>before<\/em> discovery got industrialized. <\/span><\/p>\n

The 2026 Verizon DBIR, which I covered earlier this year, found the median time to fully patch has grown to 43 days and that only 26% of KEV-listed vulnerabilities were fully remediated, while exploitation became the top initial vector at 31% of breaches.<\/p>\n

The labs know this, which is why every discovery capability now ships with a fix capability bolted next to it. That said, those fixes still require a human review before anything merges.<\/p>\n

Niels Provos made the case on the show in June that remediation is the bottleneck AI hasn\u2019t cracked, and I largely agree, with one caveat. Generating a patch has become cheap as AI has collapsed the economics there as well. <\/p>\n

The hard part is knowing whether the patch is correct, whether it breaks something three services away, whether the finding was even reachable, and who is accountable when an agent-written fix for agent-written code ships to production, and that is an AppSec program design problem more than a model capability problem, and one we haven\u2019t fully figured out yet as an industry.<\/p>\n

This is where I think much of the industry is still looking in the wrong place. <\/p>\n

\u201cShift left\u201d was built for a world where a human typed code into an IDE, opened a pull request, and a pipeline ran scanners against it. That world is ending as industry tech leaders such as Google and Microsoft highlight nearly universal adoption of AI coding tools, with big surges in AI-generated and accepted code.<\/p>\n

The important detail is what those tools are. A coding agent is a process on a developer workstation with a shell, a package manager, access to environment variables and credentials, and a set of MCP servers and skills it can call, and it takes hundreds of actions per task that no human reads. <\/p>\n

AI coding tools quietly route around your security, ignoring the authenticated route abstractions and hardened libraries your platform team built and writing raw code instead. Every one of those actions is a place where a supply chain compromise, a leaked secret, or a destructive command can happen, and it happens before there is a pull request for anything to scan.<\/p>\n

The evidence that attackers noticed is already here. The <\/span>Nx \u201cs1ngularity\u201d incident<\/a><\/strong> in August 2025 shipped malicious packages that, per the maintainers\u2019 own postmortem, \u201cattempted to use local AI tools (like Claude and Gemini)\u201d on the victim\u2019s workstation to hunt for sensitive information. <\/span><\/p>\n

The <\/span>Shai-Hulud worm<\/a><\/strong> that followed identified other packages maintained by a compromised developer, injected itself, and republished them, with its <\/span>second wave<\/a><\/strong> compromising roughly 700 npm packages using preinstall hooks. Layer on top of that the <\/span>USENIX Security 2025 research<\/a><\/strong> finding package hallucination rates of at least 5.2% for commercial models and 21.7% for open source models, across 205,474 unique hallucinated package names, and you have an agent that will confidently <\/span>npm install<\/code> something that doesn\u2019t exist yet and an adversary happy to register it.<\/span><\/p>\n

The control point for AppSec has to move to where the code is actually created, which now means the agent itself and the workstation it runs on. Additionally, the loop between the coding agent and the security platform has to become agent-to-agent, because there is no human in the middle to read a scanner output and decide.<\/p>\n

That is the frame I brought into a demo and walkthrough with Legit Security\u2019s CTO and Co-Founder Liav Caspi and CMO Dave Howell recently. Their architecture maps closely onto the two shifts above.<\/p>\n

Liav described their approach as three-pronged. <\/p>\n