Rethinking Shift-Left: More Than Just Eliminating Vulnerabilities?

Over the past few years, the concept of “shift-left” has dominated software security. The idea seems intuitive - catch vulnerabilities as early as possible in the development process, allowing teams to remediate issues long before they ever reach production. But after a recent discussions, I started thinking more critically about what shift-left actually delivers and, more importantly, where it might be falling short.

Shift-left isn’t about catching every vulnerability; in fact, that’s part of the problem. By overloading our process with too many tools that lack effective triage, we’re inadvertently creating overwhelming backlogs that hinder more than they help. True shift-left should streamline security efforts, focusing on actionable, high-impact issues instead of flooding teams with alerts that bury what really matters. It’s about saving engineers time and focusing on what actually matters. It’s less about throwing every possible tool (SAST, SCA, DAST, and beyond) into CI/CD pipelines and more about building a focused, production-informed approach to security that allows engineers to prioritize effectively.

This take aligns with critiques like those in the article “My Beef with ’Shift-Left’” [1], which argues that this approach, though well-intentioned, often leads to alert fatigue and frustration for developers. The overload of low-fidelity tools becomes a barrier to agile delivery, undermining developer productivity without necessarily solving core security problems. This setup can create an conflicting dynamic between security and engineering, where security is viewed as yet another roadblock in the path to delivering value.

Then there’s the question of cost, explored in “Shift Left Was Founded on a Lie” [2]. The article highlights that the often-cited cost-saving figures behind shift-left - like the famous claim that fixing bugs during design is 100x cheaper than after release - stem from outdated, unofficial research. The blunt reality is that if shift-left worked as promised, mature organizations wouldn’t have critical vulnerabilities in production today. Instead, many are still dealing with mountains of vulnerabilities, exacerbated by backlogs and endless alerts that provide little actionable insight.

So, what’s the alternative?

Maxwell’s perspective [1] focuses on a set of practical, production-informed priorities for API security that shift the focus from catching every possible vulnerability to creating security that is actionable, scalable, and meaningful in production. In his article you can find his wishlist.

As I reflect on this approach, I wonder if this still fits within the original concept of “shift-left.” Rather than pushing all security earlier in the development cycle, this feels like true DevSecOps, where security is woven into every phase of development and operations. Maxwell’s emphasis on runtime data, risk-based prioritization, and responsive controls fits well with a DevSecOps approach - one that brings development, security, and operations together under shared goals and pragmatic strategies.

The shift-left idea was initially about fixing vulnerabilities early, but Maxwell’s priorities reveal a bigger picture: using security to empower engineers and remove friction from the development process.

Tools alone won’t solve the problem - real change happens when we prioritize based on actual risk. For instance, metrics like KEV (Known Exploited Vulnerabilities) provide additional layers of context. Similarly, runtime agents offer insight into how vulnerable functions of a library are being executed, which can drastically change how they’re prioritized.

A Call for Pragmatism in Security

Shift-left, DevSecOps, or whatever term we settle on - the focus has to shift from endlessly finding vulnerabilities to meaningfully fixing and preventing them. The goal should be to keep security practical and aligned with engineering goals, so security becomes an enabler rather than a blocker. For those of us in security, here’s a question to consider: are we providing actionable insights that truly help engineers? Or are we contributing to a backlog that ultimately slows down progress?

As security continues to evolve, our role isn’t to make development harder; it’s to help teams build safely and deliver confidently.

[1] https://maxlikessecurity.medium.com/api-security-shift-left-is-broken-4fbc0c53db7c

[2] https://www.resilientcyber.io/p/resilient-cyber-newsletter-19