Why AI Demands a New Approach to Shift Left

By

9 minute read time

Why AI Demands a New Approach to Shift Left
11:57
Image with leftward-pointing arrows, illustrating the theme of

AI has changed the pace of software development. It is also changing the conditions under which application security programs have to operate.

The most immediate concern is not that AI can write vulnerable code. AI coding assistants and agents can make more software decisions in less time, including decisions about how to:

  • Select open source components.

  • Introduce versions and transitive dependencies.

  • Change configurations.

  • Modify build workflows.

At the same time, AI-assisted security research is increasing the volume of vulnerabilities that organizations, maintainers, and software vendors must evaluate.

That puts a new kind of pressure on AppSec. Security teams are not just trying to find more issues earlier. They need to determine which findings create real exposure, help developers make safer choices before risk enters the application, and remediate what matters at a pace that can keep up with AI-assisted development.

Mythos Did Not Create the Crisis Many Expected. It Revealed the Bottleneck.

When Anthropic announced Mythos and Project Glasswing earlier this year, the security industry anticipated that frontier models could find and potentially exploit vulnerabilities at a scale traditional vulnerability management processes could not absorb.

That worst-case scenario has not materialized publicly. But the underlying shift is real. Vulnerability disclosures have increased, particularly in open source, while validation, patching, testing, and distribution have become the bottleneck.

The near-term disruption is more defender-led than attacker-led. More capable AI models are accelerating both vulnerability discovery and software development, creating more decisions across the software supply chain. AppSec programs must be ready for both.

Confidence Is High. The Operational Data Is More Complicated.

In July 2026, IDC surveyed 309 security and engineering leaders about AI-assisted vulnerability discovery and AppSec readiness.

Concern was real, though not universal. IDC found:

  • 40.1% were very or extremely concerned about models such as Mythos identifying substantially more vulnerabilities.

  • Another 26.5% were somewhat concerned.1

Yet organizations expressed strong confidence in their readiness. Nearly 87% described themselves as at least somewhat prepared for a significant AI-driven increase in discovered vulnerabilities, and 37.2% said they were very prepared to validate, prioritize, and remediate findings at scale.2

That confidence conflicts with current practice. IDC found that 55.6% of organizations allow known critical application security vulnerabilities into production at least occasionally, and nearly one-third do so monthly or routinely.3

Not every critical finding should block a release, but severity alone does not identify real exposure. Preparedness depends on prioritizing the vulnerabilities that matter most and resolving them before faster discovery becomes production risk.

More Discovery Alone Does Not Create Better Security

Most AppSec teams already manage a backlog. More than half of IDC survey respondents reported at least 1,000 open application security findings, while 26% reported at least 5,000. The problem is not just volume. It is flow. In a typical month, 39.8% of organizations receive more new findings than they remediate, and only 20.4% remediate faster than new findings arrive.4

AI-assisted discovery can add more findings to that system. Without corresponding improvements in validation, prioritization, and remediation, it will simply make the backlog larger and older.

This is the practical meaning of the AI-era shift left. Finding an issue earlier remains valuable, but it is no longer sufficient to treat scanning as the end of the security process. Teams need enough current context to distinguish between a finding that is merely present and one that creates meaningful exposure. They also need a clear path to a safer component, version, configuration, or code change.

The goal is not to turn every developer into a security analyst or force every release through a manual review queue, but to make safer decisions easier at the moment they are made.

AI Is Increasing Security Work Across the Software Lifecycle

AI coding adoption is already widespread. IDC found that about 99% of organizations are broadly using, approving, piloting, or otherwise encountering AI coding tools. At the same time, 90.3% said they were likely or very likely to use agentic AI in AppSec during the next 12 months.5

That is not a future-state planning problem. It is an operating-model problem happening now.

Organizations reported that AI coding assistants and agents are increasing security workload at every stage:

  • 67% reported increased security findings during development.

  • 61% reported increased review and remediation effort.

  • 48% reported more findings reaching production.

  • 74.5% agreed that AI coding assistants increase the risk that developers merge code they do not fully understand, even when scans pass.6

Passing a scan does not guarantee that a developer or agent understood the dependency decisions, configuration changes, or system-level effects introduced by generated code. AI tools can be highly effective at completing a task, but their context is often limited to that task. They do not automatically understand the organization's approved components, security policies, deployed environments, or the current risk posture of every dependency they recommend.

That's why AI-generated code and agentic workflows now rank among the top AppSec and software supply chain risks in IDC's research.7 They sit alongside the risks security teams already know well in dependencies, provenance gaps, build controls, and exposed secrets. AI is not replacing the software supply chain problem but making the problem more dynamic.

Dependency Sprawl Is a Security and Scale Problem

Sonatype's analysis of two open source projects shows why traditional review processes struggle at AI speed. The Spring Framework, a mature and predominantly human-developed project, contained 764 open source components across its dependency tree. An agentically developed open source project contained 2,543 dependencies across four languages and was changing much faster.

These examples do not represent every human- or AI-developed project. But they illustrate a broader pattern of how AI agents can introduce components from a vast pool of libraries faster than human reviewers can evaluate them. That expands the software supply chain teams must assess when a vulnerability, malware campaign, maintenance issue, or policy change emerges.

Sonatype Research Labs found that Critical and High vulnerabilities per application increased 4.31x during the AI era, reaching an average of 54.3 by 2026 in a fixed cohort of enterprise applications. New vulnerability advisories also grew fourfold over 49 months. AI is not the only cause, but organizations are managing more software change and more security information at once.

Shift Left Now Means Bringing Intelligence to the Decision

For years, shift left has meant moving security testing closer to development. That remains necessary, but AI requires a more specific version of the practice.

Security needs to move upstream to the decisions that create downstream work: which component an AI assistant recommends, which version a developer selects, if a policy exception is justified, and if a newly introduced dependency is appropriate for the organization's environment.

That requires three capabilities:

  • Current, software-specific intelligence. Developers and AI systems need more than a model's historical knowledge. They need current information about component risk, known malicious packages, available safer versions, maintenance status, and organizational policy.

  • Risk-based prioritization that reflects real exposure. Teams must be able to focus remediation effort on vulnerabilities that are reachable, exploitable, or otherwise material in their environment instead of treating every finding as equivalent.

  • Developer workflows that support speed and control together. Guidance and policy should appear in the tools where developers and agents make decisions, with clear remediation paths that reduce rework instead of adding a late-stage gate.

This is not a choice between prevention and remediation. Organizations need both. Faster remediation is essential for the software already in production, and AI can help teams address some longstanding security debt. But prevention becomes more valuable as the rate of software assembly increases. Avoiding an unnecessary risky component is better than discovering it in a scan, triaging it in a backlog, and fixing it after it has already created work.

Build at AI Speed Without Scaling Risk

The Mythos conversation brought attention to a plausible future in which vulnerability discovery scales dramatically. The more immediate lesson is that the conditions for that future are already forming: AI is accelerating code production, dependency selection, software change, and security research at the same time.

AppSec programs cannot meet that change by asking manual review and remediation processes to absorb unlimited additional volume. They need a clearer view of their current backlog and release practices, better prioritization of actual exposure, and controls that help developers and AI agents make safer component decisions before risk enters the application.

That is what shift left means in the AI era: not simply finding more issues earlier, but giving the people and systems building software the intelligence to avoid unnecessary risk from the start.

To see the research and dependency analysis behind these findings, watch the on-demand webinar "What Shift Left Means in the AI Era" with guest speaker IDC Research Director Katie Norton and Sonatype Field CTO Ilkka Turunen.

Footnotes

1 IDC, DevSecOps and Software Supply Chain Security Survey, July 2026, n=309. The 40.1% figure is a calculation combining the 27.8% "very concerned" and 12.3% "extremely concerned" responses.

2 IDC, DevSecOps and Software Supply Chain Security Survey, July 2026, n=309. The "nearly 87%" figure is a calculation combining the 37.2% "very prepared" and 49.5% "somewhat prepared" responses.

3 IDC, DevSecOps and Software Supply Chain Security Survey, July 2026, n=309. The "nearly one-third" figure is a calculation combining the 21.0% "frequently" and 10.7% "routinely" responses.

4 IDC, DevSecOps and Software Supply Chain Security Survey, July 2026, n=309. "More than half," "26%," "39.8%," and "20.4%" are calculations from the survey response categories.

5 IDC, DevSecOps and Software Supply Chain Security Survey, July 2026, n=309. "About 99%" and "90.3%" are calculations from the survey response categories.

6 IDC, DevSecOps and Software Supply Chain Security Survey, July 2026, n=309. The 67%, 61%, and 48% figures combine the survey's moderate- and significant-increase responses.

7 IDC, DevSecOps and Software Supply Chain Security Survey, July 2026, n=309.

Picture of Aaron Linskens

Written by Aaron Linskens

Aaron is a technical writer at Sonatype. He works at a crossroads of technical writing, developer advocacy, and information design. He aims to get developers and non-technical collaborators to work better together in solving problems and building software.

Tags