Shift left security — Good intentions, poor execution, and ways to fix it

The concept of “shift left” is fundamentally sound. Integrating security earlier into the software development life cycle (SDLC) seems like the obvious move. Instead of leaving security as an afterthought, why not address it before it becomes a problem? It sounds ideal: Faster remediation, fewer vulnerabilities slipping through the cracks, and developers becoming security heroes. Hooray!

However, despite the appeal, shift left hasn’t quite lived up to its promise. The intention is clear, but the execution leaves much to be desired. While our industry has tried to move security earlier in the process, the way it has been done isn’t working for developers.

I’ve experienced this firsthand, and I believe there’s a better way to fulfill the original promise of shift left.

Where Shift Left Falls Short

The whole premise of shift left is to put security into the hands of developers, empowering us to manage the risks associated with the code we write. In theory, this decentralizes security, giving those of us who are closest to the code more responsibility in protecting it.

But for this to work for us, we developers need to be able to make sound security decisions. To me, “able” translates into three things:

1. We need to actually want to do it. Right now, we don’t. Developers are not incentivized to focus on security. Our goals are centered around shipping features and meeting deadlines and we tend to see security as something that slows us down. The tools we’ve been given are often more about helping security teams catch our mistakes after the fact rather than helping us prevent them. This ‘security cop’ posture means that we mostly experience security through frustrating “Hey, I caught you red-handed” notifications which create a disconnect and leads to resistance rather than engagement.
2. We need tools that do not ruin our velocity. Many of the tools marketed as “dev-friendly” integrate into our development toolset — Jira and Pull Requests notably — but don’t try to fit into our way of working. They’re not “dev-friendly”  they’re just “dev-compatible.” They typically show up later in the SDLC, after code has been committed. They alert us too late, adding unnecessary context-switching and forcing us to revisit and fix code that we’ve already moved on from. Not even mentioning redundant peer reviews. It’s an inefficient process, and it contributes to a general frustration with security.
3. We need to acquire cyber judgment (preferably without being bored to death). Developers love to learn – yes, even security stuff – but not on things we may never encounter. The industry’s approach to security training expects us to spend significant time learning through lengthy and generalized training programs that don’t align with our specific needs. The result is that many of us view security training as an interruption rather than an opportunity for growth. It’s hard to stay motivated when the training feels disconnected from our prior knowledge and our day-to-day work.

How We Can Make Shift Left Work

The good news is that shift left isn’t beyond saving. The concept still has immense value – if we can execute it better. The key is to address these three points above in such a way that security feels like a natural extension of the work we’re already doing, rather than a series of external demands.

Here are some specific ways to make this a reality.

1. Security as a Coach, not a Cop. One of the first steps is changing the way security is integrated into development. Instead of focusing on a “gotcha”, after-the-fact approach, we need security to assist us as early as possible in the process: as we write the code. By guiding us as we’re still in ‘work-in-progress’ mode with our code, security can adopt a positive coaching and helping stance, nudging us to correct issues before they become problems and go clutter our backlog. This approach would reduce the stigma around security and make it something developers see as beneficial, rather than a penalty.
2. Tools that don’t make us work twice. The security tools we use need to catch vulnerabilities early enough so that nobody circles back to fix boomerang issues later. Very much in line with my previous point, detecting and fixing vulnerabilities as we code saves time and preserves focus. This also reduces the back-and-forth in peer reviews, making the entire process smoother and more efficient. By embedding security more deeply into the development workflow, we can address security issues without disrupting productivity.
3. Targeted training. When it comes to security training, we need a more focused approach. Developers don’t need to become experts in every aspect of code security, but we do need to be equipped with the knowledge that’s directly relevant to the work we’re doing, when we’re doing it — as we code. Instead of broad, one-size-fits-all training programs, let’s focus on addressing specific knowledge gaps we personally have. Real-time training, delivered in small, digestible portions as we encounter specific challenges in our code, would be far more effective. This just-in-time approach allows us to learn in context, on the job, making the training more memorable and directly applicable.

Ironically, in the end, fixing shift left security requires us to double down on the original idea, pushing security even further to the left — into the code as it’s being written, and into the knowledge base of the developers writing that code. By taking a more integrated, supportive approach to security, we can turn security from an obstacle into a personal win.

The potential for shift left remains vast, but to unlock it, we need to rethink how we execute on the promise. With the right tools, mindset, and training, developers can be empowered to make security a natural part of the development process. That’s how we’ll finally deliver on the promise of Shift Left Security.