What problem are we actually solving by shifting security left?
That is not a rhetorical question. It is a real one, and if you do not have a clear answer, you are not alone. For many teams, “shift left” security has become a checkbox mantra. It is the sort of thing you put in a presentation to show your org is modern, collaborative, and serious about DevSecOps. But if you peek behind the curtain, you often find something much messier.
Let’s back up for a moment.
The idea of shift left security started with good intentions. Around 2015, as DevOps practices matured and tools like Jenkins, GitLab, and early SAST/DAST integrations gained traction, security teams were told to catch up. The earlier you identify security issues in the development lifecycle, the cheaper and easier they are to fix. That insight is not wrong. It is backed by decades of software engineering research. So the concept took off, especially as organizations embraced agile and DevOps. Instead of waiting until the end of the cycle to run vulnerability scans or pen tests, why not integrate security testing earlier? Train developers. Write secure code from the start. Automate the boring stuff. All of that makes sense.
But then the implementation began.
Security teams, often underfunded and understaffed, were told to go teach development teams how to write secure code. One developer told me, ‘Every security ticket we get is vague, late, and blocking something that matters. It’s noise. Most of them had neither the bandwidth nor the curriculum to do that. The software equivalent of Daft Punk lyrics, developers lived, “Work it, make, do it, harder, better, faster, stronger.” Developers, for their part, were trying to survive two-week sprints, drowning in Jira tickets, and being measured by how many features they shipped, not how secure they were.
So we got a compromise.
Check box mentality DevOps. Security folks started dropping Jira tickets into development backlogs. Despite years of shift-left adoption, most organizations still report critical issues making it to production. Breaches tied to basic application flaws like authentication bypasses or missing access controls keep showing up. They added static analysis tools to CI/CD pipelines. They sent out cheat sheets and “secure coding best practices” documents. Maybe there was a lunch-and-learn or two. Maybe the AppSec team got one security champion in each dev squad. But the organizational incentives never changed. Developers were still judged by speed, not safety. Security was still an afterthought unless something blew up.
That is not shifting left. That is outsourcing blame.
I find it interesting when I sit down with developers and they immediately declare that I obviously don’t know anything about software coding. My bachelor’s degree in computer science, master’s degree in computer science, and decades of writing low-level drivers and back-end systems apparently don’t count. The movement toward anybody can code, you don’t need a degree, an 8-week bootcamp, and you can be turned loose writing annuity programs for an insurance company doesn’t seem very useful to me. These are cultural issues, but there is a host of other constructed reasons why shift-left has become an issue.
Here are five things that explain why this fails:
- The Training Fallacy: Expecting developers to become security experts overnight is not realistic. Many developers never received formal secure coding education. A few hours of training once a year does not change that. It is like giving someone a CPR manual and assuming they are ready to work in an ER.
- The Visibility Trap: Security issues dumped into a backlog rarely rise to the top. They get buried under feature requests and hotfixes. Without real priority or visible consequences, they are treated as optional.
- The Metrics Disconnect: Sprint velocity, code coverage, and shipping deadlines still drive decisions. Secure code that slows things down gets cut. Security work that delays release is seen as a blocker, not a feature.
- The Authority Problem: AppSec teams often lack the authority to enforce requirements. They can suggest. They can escalate. But they cannot force development to fix issues before moving forward. And when production fails, blame goes in both directions.
- The Tooling Mirage: Automated tools help, but they are not a substitute for human review or structural changes. Running a static analyzer does not magically create secure architecture. It often produces false positives, which frustrate developers and erode trust in security recommendations.
So what does doing it right actually look like?
- Security Engineering Over Ticket Filing: Instead of hurling Jira issues into the void, embed security engineers in the dev cycle. Not as scolds or auditors, but as design participants who help build secure systems from the start. I didn’t sneeze, and I didn’t say architects.
- Change Incentives, Not Just Tools: If developers are rewarded only for speed, security will always come second. Doing sprints where security is not a priority, with a promise to take care of it later, is like using your children as alligator bait. Organizations must align metrics and promotions with secure outcomes. That might mean rewarding teams for zero critical vulnerabilities, not just shipping on time.
- Invest in secure libraries and patterns: Make the secure path the easy one. A golden path. A way out of the jungle. Build and maintain hardened libraries and templates that developers can use without reinventing the wheel. This is how cloud providers and big tech companies enforce guardrails without being oppressive.
- Treat Developers Like Allies, Not Problems: Many developers care about security. They just need the time, tools, and support to do it right. We always nod vigorously that security must be aligned to the business, but that is half the issue. The business must be aligned to do things securely in the first place. Anything else is rowing across the Atlantic with one oar. Respect their constraints and collaborate to remove friction.
- Build Organizational Muscle: Shift left should not mean security shifts away. It should mean security becomes a shared responsibility, with dedicated engineering support, meaningful metrics, and leadership attention. This takes time, resources, and executive commitment. Your IT infrastructure gave you thousands of times more efficiency, and you built your house out of kindling in a forest fire and are arguing about buying a fire extinguisher.
So back to the question: what problem are we really solving with shift left security?
If the answer is “so we can blame developers faster,” we are doing it wrong. If it is “so we can avoid security rework late in the cycle,” we need to prove that with outcomes, not just dashboards. The real danger isn’t just that shift-left fails. It’s that it gives everyone a false sense of security. You can have a clean CI dashboard, a stack of closed Jira tickets, and still push broken code into production. If it is “so we build more secure systems collaboratively,” then we must invest in people, process, and technical design to make that true.
The better question might be: What if instead of shifting left, we shifted ownership? What if security stopped being a tax and became part of how we design, build, and measure quality from the start?
Until we answer that, all we are doing is moving the line where we start pretending to care.
There is a conversation about this topic on LinkedIn
About the Author
