The catch-phrase "shift left" has reached peak assimilation in the application security ethos as security pundits, DevOps strategists, app sec pros, and plenty of promoters of the concept have grabbed onto the phrase as shorthand for explaining how software teams can solve the world's software security woes.
The underlying principle is that app sec needs to shift security involvement earlier in the development lifecycle — to the left of the deployment timeline — to ensure that developers deliver requirements before much dev work is done, and that app sec teams find flaws earlier in the process, when it's easier to make fixes.
While this shift makes sense in principle, many software security stakeholders have grown to hate the term as it is used today, said Michelle McLean, vice president for Salt Security.
"The term 'shift left' has its roots in a noble concept — we should do everything we can to reduce security threats as code is being developed, versus waiting until that code is running production. There’s nothing wrong with that idea. The problem is that 'shift left' has been treated as a panacea by some — that we can solve ALL of our security needs in the development phase. That’s simply not possible."
—Michelle McLean
Here's why some security practitioners see "shift left" as a dirty term that's out of touch with software development and security operations realities — and what they think app sec teams should focus on instead.
[ Get the new report: The State of Software Supply Chain Security 2024 | Join the conversation: Webinar: State of Software Supply Chain 2024 ]
Don't believe the hype on shift left
The panacea messaging associated with shift left comes from the kind of simplification that lax marketers are prone to when they're under the gun to sum up a value proposition in a few words. Unfortunately, approach this has devolved "shift left security" into a hand-waving nod to modern software security practices without actually communicating much substance.
Part of the problem is that many continue to talk about shift left as though it's an app sec magic wand, even as the term has lost its relevance in the realities of modern software delivery, said Andrew Hay, COO at LARES Consulting.
As many continuous integration/continuous delivery (CI/CD) advocates will tell you, many modern software organizations started that shift a long time ago. They're adopting earlier testing, adding security scrutiny, and automating test tools to accomplish the shift, Hay said.
"The term 'shift left' once meant something when everyone performed testing at the end of the development cycle. I hated the term when it was DevSecOps, and I hate it even more now that it's been given a pseudo-philosophical facelift."
—Andrew Hay
Developers dislike 'fake' shift left
Developers often see shift left as suspect because it's frequently used as a way to move the same old security testing and validation methods earlier in their development cycles. They're simply interrupting the workflow at an earlier stage, without actually making developer workflows any more effective or elegant, said Scott Gerlach, co-founder and CSO at StackHawk.
"You can’t just take old processes and move them into CI/CD or developer workflows and expect them to be successful."
—Scott Gerlach
The impetus behind the shift left movement was not just about doing the work earlier, but also democratizing a lot of that security work by providing easier tools for developers to do so as they went about their business writing code. That's still not happening in many cases. A recent report from CloudBees found that 80% of organizations are "doing shift left," but 60% of those companies said it has become a burden on dev teams.
"You have to figure out how to empower your dev teams with useful and actionable information, and help them make decisions. Not letting dev teams make and document decisions is a real momentum killer in shift left."
—Scott Gerlach
The security buck still stops with the SOC
Even when shifting left in a way that enables, rather than creates roadblocks for developers, McClean warns that "it's risky for security teams to put their destiny in the hands of developers."
What McLean and many other security advocates point out is that all of the stuff on the right still matters, for many reasons.
First of all, shifting security left on new applications doesn't do a whole lot for securing an organization's current software assets. Second, testing in pre-production is not going to cover business logic gaps or other flaws that can occur when developers deploy and integrate code into live environments. For example, in the case of API security, exploits depend on a sequence of API calls that typically can't be tested statically, she says.
More fundamentally, though, it comes back to security assurance. At the end of the day, the buck stops with the security organization—and those running the security operations center (SOC) must have ways to verify that 'shift left' is working.
Gregory Crabb, founder of 10-8 Cyber, said in the recent ReversingLabs special report, Software Supply Chain and the SOC: End-to-End Security is Key, that SOC teams need to use tools such as real-time package analysis and other testing of production code to identify security issues in application behavior across the entire software lifecycle.
"Not only do you need the controls of shifting left, but you also need to be able to validate the performance of the controls and the integrity of the process."
—Gregory Crabb
How to get smart with any shift in app sec
There's definitely a love/hate dynamic that surrounds the use of the shift left term, said Larry Maccherone, Dev[Sec]Ops transformation architect for Contrast Security. A longtime advocate for weaving security best practices into DevOps and CI/CD pipelines, Maccherone says it reminds him of the Eric Hoffer quote, "Every good cause begins as a movement, becomes a business, and eventually degenerates into a racket."
"The term shift left is not yet a full-blown racket, but it'll get there if we aren't careful."
—Larry Maccherone
Instead, Maccherone said, app sec teams should "shift smart" by roughly dividing applications into two buckets. The first should contain actively deployed applications that are continuously updated to add functionality. These are good candidates for applying 'shift left' philosophies, as long as the organization doesn't shift too far left too fast.
He stressed that there needs to be a cultural app sec transformation, with a gradual on-ramp. It's best to focus on fixing a small number of vulnerabilities fast, rather than finding tons of flaws and letting them sit in inventory for months, he said.
"You can’t expect development teams to immediately be worthy of being trusted with the security of their software. Set the policy dial really low at first."
—Larry Maccherone
The second bucket should contain maintenance-mode applications that still produce value, but only receive bug or vulnerability fixes, because this is where runtime protections kick in. "You don’t want to shift left for maintenance mode applications at all, because there is no one to shift left to," she explained.
McClean has increasingly heard people use the phrase "shift left and shield right," but said it might be better to suggest "start right, then shift left" to better convey how important it is to implement immediate protections against running assets.
"Deploy protections now against your running assets to stop attacks, then implement shift left. It takes a lot of work and a lot of time to train developers, implement the tooling, instrument the CI/CD pipeline to integrate with the feedback of shift-left tooling, etcetera. If you wait until you get all that right, you’ll be VERY exposed."
—Michelle McLean
[ Get report: Software Supply Chain and the SOC: End-to-End Security is Key | See special report: The Evolution of App Sec ]
