I recently read a thought-provoking post on LinkedIn from Aquia CEO Chris Hughes on shift left. In this post, Chris takes aim at the history of the shift left concept, sparking a heated discussion in the comments section. He also created a deep analysis blog post on the topic that breaks down much of his research on the history of shift left. Also, a while back, my colleague Melinda Marks wrote about her issues with the term ‟shift left”, citing findings from her research. Today, in a conversation with some cybersecurity friends, I realized that I am in a unique position to elaborate on the idea of shifting left, having been in application security since the 1990s. Let’s go back in time a bit.
Early Days: Embracing Shift Left
First, let me set the stage. Shift left is the idea that moving security assessment and thus finding security issues earlier in the development cycle is significantly more resource- and cost-effective than finding the same security flaws later in the development lifecycle or post-release. Sounds straightforward and makes logical sense, right? If we find issues while we are writing the code the first time, it takes seconds or minutes not to make the mistake in the first place. However, in my experience, the concept of shift left is an outdated theoretical ideal that once made sense but might no longer be the goal that cybersecurity professionals and developers should strive for.
A Flashback to My Younger Days
In the early 2000s, I joined one of the planet’s premier application security consulting firms, @Stake. A majority of Fortune 100 companies hired us to help them fix their cybersecurity problems. Our client roster included many household names, such as IBM, BestBuy, Microsoft, and even the Office of the President of the United States of America—yep, I was on that project. I learned from some of the best hackers in the world. I was even recruited to be part of the “@Stake Application Security Center of Excellence,” where we were explicitly tasked with pushing the boundaries on the best way to help our clients find and fix security issues in their applications and code. I will not go so far as to say that we “invented” shift left. We obviously didn’t—see this great post on security first principles—but the concept was something that we heavily pushed, helping our clients move from late-stage penetration testing to security techniques that existed much earlier in the development process. We helped clients implement threat modeling in the design phase, code reviews throughout the development process, and application architecture assessments to ensure the entire project was designed based on strong application security principles. Shift left was exactly what we taught others as we felt it was the best way to create a more secure Internet.
The Evolution of My Perspective
One of the critical concepts for you to understand is what software actually looked like back in that era. First of all, developers wrote their own code. The world hadn’t yet fully shifted to open source and code reuse models that modern developers embrace. According to the 2024 Synopsys OSSRA report, today, over 77% of a typical codebase will be open source code. We had to write most of the lines of code ourselves and didn’t merely glue together already-created components. To make matters worse, DevOps and software as a service wasn’t really a thing either. That meant that we used waterfall-based models of development that took 12 to 18 months, and in that time frame, we would release one new version of the application. We burned it to a CD-ROM and had a physical assembly line package up the software so that we could ship new versions to our customers to upgrade with. Not only did we ship once every 18 months, but we expected our customers to pay for the new software version again.
If you think about this for a second, you quickly see why finding a security issue, or any bug for that matter, after you “released” your software was costly. As a matter of fact, you often wouldn’t even fix some issues because the cost of redevelopment was way higher than the risk to the business running the packaged software. You would just roll the fixes into the next version to be released in another 18 months, and customers put some kind of mitigating factor—firewalls, for example—in place to ensure they were secure. It made a lot of sense to shift left to fix the problems before you spent all of the money on the distribution of your software. You needed to build a security-focused development approach.
Microsoft was a prime example of embracing the shift left approach in 2004 when Bill Gates penned his infamous “Trustworthy Computing Memo” The approach required fundamental research and engineering advances, specifically in the following areas:
- Developing new security tools, methodologies, and training.
- Prioritizing security and privacy in the engineering culture.
- Formalizing a requirement for the software development lifecycle for many software products.
- Making it easier for users to enable automatic updates.
However, times have changed, and application security concepts must also change.
Current Stance: Shift Left Needs To Be Rethought
We no longer ship code on CDROMs or develop in 18-month release cycles. We’ve learned DevOps practices and the idea of code reuse by open source. We access our application not as a software product but as a “software-as-a-service offering.” Everything is internet accessible and interconnected, making software a fundamental piece of everyday life, not just a technology we need occasionally. Infrastructure has moved from the data center, where business teams access local offerings, to cloud native technologies built in distributed architectures using microservices models. All of these changes have made the concept of shift left a bit of a novelty idea that makes sense in theory but not really in practice.
Modern application design does not work well with shift left approaches to cybersecurity. Let’s break down the specific reasons:
- Software is no longer a product, it’s now a service. The switch from product to service business approach drastically changes how application security and shift left should work. Services are continuous and always on, and so must be the delivery of security fixes.
- Release cycles are continuous. Modern software is delivered continuously, existing in a state where updates and modifications can and often do occur in real time. Every time we log into a modern web-based application, we are likely to see updated features or code. Many systems are updated continuously, with constant A/B testing and bug fixes being shipped many times per hour. The time to deploy, not necessarily code, a security fix is nearly zero in this modern model.
- Application sizes have shrunk to the function level. The whole point of shrinking the unit of development is to build chunks faster and to provide agility to how we execute fixes and updates. In modern application development, the atomic unit of development is approaching the size of an individual function. We are essentially releasing function updates continuously instead of product updates once every two years. This enables developers to fix security issues nearly immediately. Microservices and cloud-native development don’t just speed up functional release, they speed up security fixes as well.
- Code reuse makes it easier to fix security issues quickly. The ability to simply upgrade a library or chunk of code by modifying an include statement provides a rapid way to resolve problems. While we outsourced the remediation of the issue itself to the library maintainer, that can result in delays. In an ideal world, if enough people are affected by an issue, the library maintainer is incentivized to fix the issue very quickly. We simply need to keep up to date on our library usage.
Future State: Moving Beyond Shift Left
Is shift left so outdated and useless that we should abandon the practice and instead focus on something else? No, it’s not quite that simple. Shift left should not be abandoned as a primary principle to help us think about the most cost-efficient way to build software. Instead, it should be one arrow in a quiver of technologies, tactics and processes that we can use to create secure code for our customers. Shift left must be reconsidered in light of modern software approaches. It’s no longer good enough to find vulnerabilities earlier. That approach has failed. We must embed security into multiple simultaneous continuous development processes in a way that is fast enough to fix discovered issues quickly. Shift left is an ideal that we should reconsider against the backdrop of our current development methodologies and infrastructure designs.
Development is done completely differently than it was 20 years ago, and it’s undergoing an even more fundamental shift as we move to copilots and AI-driven development. Security, infrastructure and cloud technologies have completely revolutionized how development occurs—so why do we continue to cling to historical ideals without actively putting in the thought to consider that an updated, more holistic approach might exist?
- Observability is a driver for vulnerability discovery.
- Real-time production debugging pushes boundaries when finding and fixing flaws.
- Microservices models enable function modification and updates for security fixes with no downtime.
Developers can track and fix issues faster than ever before, so why do we have to invest so much money upfront when midproduction security processes and post-release rapid remediation are possible? Would you rather spend $1 million to catch all of your security flaws up front for a theoretical near zero-risk release of your product or $100,000 in automation, analysis and rapid remediation to have a very limited window of attack that is fixed nearly as quickly as issues are found? While the numbers are made up, the concept is directionally accurate. We can fix things so fast now that it might not make sense to spend all that money upfront and slow down your development speed.
Conclusion
I’ve seen so much change in development approaches, models and processes in over two decades of close involvement. While I definitely do not consider myself the best developer in the world, I have been present as the developer journey has progressed into what it has become today. The primary thing I’ve learned over that time is that things change, and those stuck in the mud and refusing to analyze how we approach a process are doomed to make the most significant mistakes over the long term. At TechTarget’s Enterprise Strategy Group, I look forward to reading Melinda’s upcoming research analyzing our progress in supporting modern development. Feel free to reach out to me or Melinda for additional details. For the security practitioners out there, I expect each of you to take a step back and seriously consider that maybe, just maybe, the ideals we have been telling the world for our entire lives might not be entirely accurate, and there are opportunities to find better solutions to our challenges. Let’s be introspective and see if we can make things even better than they are today.
