“Shift left” has become a favorite mantra of engineering, IT and software teams. The idea is simple: Move critical practices earlier in the development process so that problems can be caught sooner and fixed more cheaply. It started with testing, then design, then DevOps, and now it’s security’s turn. Secure by design, secure by default. Just shift it left.
But there’s a problem. If you shift everything left, what’s on the right?
The term “shift left” sounds appealing, but it’s based on the notion that software development is a neat, linear process with design on the left and production on the right. That model might make sense on a Gantt chart, but real-world software is complex and messy. And complex and messy have important implications for how to think about security.
Code (and attack surfaces) don’t flow from left to right. They unfold across overlapping zones of activity that run in parallel. Some people are designing, some are coding, some are deploying, and others are investigating anomalies in production – all at the same time.
Security Needs to be Embedded
Security isn’t something you can “move left”. It’s something that needs to be embedded in all zones.
DevOps security is an extension of and should still conform to the organization’s overall enterprise security, compliance and governance policies. This ensures that the code that is developed and deployed meets the organization’s security requirements.
Optimize within a zone, sure. It’s important to do as much as possible early: threat modelling, secure coding and static analysis. That’s good hygiene. But those only address the development zone. The real world doesn’t stop there. Security in the production zone is just as critical: monitoring, detection, alerting, incident response and continuous improvement. These aren’t things you can shift anywhere. They’re tied to live, active systems. They happen where the threats are.
The irony is that shifting security left too far can give teams a false sense of safety. Boxes are ticked. Static scan looks good, threat modelling is done, so we must be secure. But attackers don’t care how early your checklist ran. They’re looking at the state of the system now.
The real issue is that we keep using linear metaphors for systems that aren’t linear. Software delivery is a dynamic, concurrent set of activities. Tasks feel linear because humans experience time that way, but the system as a whole behaves more like a living network. A dancing landscape that’s constantly adapting, feeding back, and evolving.
Security has to live across that system, moving as the landscape moves, not at one end of it.
You can absolutely optimize within a zone and make developers more security-aware and catch more vulnerabilities early, but that’s local optimization. It doesn’t make the system secure. A secure system is one where all zones are considered and continuously connected. Insights from incidents feed into design. Monitoring informs coding decisions. Security isn’t a phase; it’s a characteristic.
The challenge, then, is not to blindly start trying to shift security left, but to embed it everywhere in zone-appropriate ways. It may have made sense in organisations where security was treated as a final gate, though that, hopefully, is a practice far behind us these days, but thinking linearly doesn’t capture the reality of complex modern delivery. Real security is not about how early you start, but how continuously you adapt. Anything less risks being security theatre — reassuring on paper, but irrelevant to the real-world threats your systems face.
