It's beginning to look like the ‘‘shift left’’ approach to application security (AppSec) is falling to pieces.
The idea behind the shift-left philosophy is logical — embed AppSec best practices and code checks earlier into the software development lifecycle (SDLC) to eliminate vulnerabilities before they ever make it into production — and it has its merits. But once the marketers of code-check tools got hold of the phrase, it became easy to ignore the best-practices part of the idea.
And the simplicity of the phrase "shift left" made many software development teams with underdeveloped security practices believe that they could replace security oversight and cooperation with a simple AppSec testing tool that they could make the developers use.
Unsurprisingly, organizations that have shifted left are still exposed to vulnerabilities and malware, unable to cope with the rise of AI-based development and software supply chain threats. The old industry joke that someone left an extra F in "shift left" doesn't have anyone laughing anymore.
AppSec experts and software risk managers on SecOps teams say organizations must move beyond shift left. Here's why — and how to make that happen.
[ See Special Report: Secure Your Organization Against AI/ML Threats ]
Shift left has been dominated by tool-centric thinking
In a recent thought piece on shift left, Chris Hughes, CEO of Aquia, noted that it is human nature to look for quick fixes to complex problems. It follows, then, that many people want to believe vendors when they say they have a shift-left solution to AppSec in an easily accessible tool that fits right into the continuous integration/continuous delivery (CI/CD) pipeline — just as people who are desperate to lose weight will grasp at anything that promises to make that easy.
“Tool-centric thinking is the Ozempic of the cybersecurity thinking.”
—Chris Hughes
But the first proponents of shift left considered code scanning to be just a small part of the process. More important were getting security involved in requirements, giving developers more intensive training in secure-coding principles, and cooperating on security oversight across the software development lifecycle (SDLC). But all that software security stuff is hard, so it got pushed aside.
Overblown expectations for vulnerability elimination
Hughes’ thought piece was followed up with a podcast with some industry analysts. During that, James Berthoty of Latio Tech said one problem with shift left was that a lot of people got the notion that it would bring the pre-release vulnerability count down to zero, freeing staff to focus on backlog issues.
“I continue to hear that from CISOs: 'If only we could stop the vulnerability bleeding.' But it fails to understand how vulnerabilities get created as far as getting discovered over time where that [vulnerability] counter is only going to go up into the right. You're not making it go down."
—James Berthoty
He added that there is no business justification for letting shift left block release pipelines, with developers having to fix stuff before anything gets deployed. "Especially when 90% of these things are false positives, it's objectively a waste of time to have developers fix most of this stuff,” Berthoty said.
Cost-reduction assumptions are also wack
Shift left has a bigger problem, in that many assumptions about cost savings were based on a flawed piece of research from the 1980s that stated that finding and fixing flaws during design was 100 times cheaper than after implementation. Hughes pointed out that a recent report from the U.S. Cybersecurity and Infrastructure Security Agency (CISA) took this research to task.
Tyler Shields of ESG Research noted that some assumptions about those huge savings came from a different era of development.
“If you wrote code, you packaged it, you burned it to CDs, you actually sent it to a company that put packaging around it and then sold it. Shifting left was hugely important because if you could move bugs earlier in that life cycle, you saved distribution costs, burning costs, and so on."
—Tyler Shields
That's not how software is built and delivered today. Now that software development has moved to CI/CD, shift left doesn't make logical sense: The lifecycle is no longer linear,
Melinda Marks, a colleague of Shields' at ESG, has been airing out this concept for a while now, Shields said.
“My question is, 'Does it really make sense to worry too much about finding vulnerabilities earlier when if you did find them in the wild, you can fix them in 18 hours?'”
—Tyler Shields
Shift left turned into shifting responsibility from AppSec to devs
A big part of the initial push toward shift left was the same concept that pushed DevSecOps into the limelight: AppSec responsibility needs to be shared by everybody. However, somewhere along the way, shift left became a way to offload work to the developer corps.
Longtime AppSec practitioner Tanya Janca of SheHacksPurple said in a recent virtual conference talk that shift left wasn't supposed to mean making developers do all the security work.
“We don't get to sit back and be like, 'Well, our work here is done. The devs are just going to handle that. They don't need any oversight. They don't need any advice or guidance. They don't need training. They don't need assistance. They don't need support.' No, that's definitely not what shift left means."
—Tanya Janca
Shift left often ignores everything that happens on the right
Janca said many people misinterpreted the shift-left movement as a way to ignore all of the security issues and controls that need to be addressed during the rest of the SDLC. The original idea got warped, she said.
"We started talking about shift left so that security wouldn't find out about new software five minutes before it goes live. We didn't want to launch new things that were a giant Dumpster full of holes. [Shift left is] not a replacement for a real security program. What it is supposed to mean is starting security right at the very beginning and going all the way through the SDLC.”
—Tanya Janca
That dumbing down also irks Chris Romeo, co-founder of Devici Security, who noted that many in the industry eventually saw problems to the right — things such as weaknesses in applications at runtime, new vulnerabilities found in dependencies, and infrastructure configuration issues. So that led to a new term: shift everywhere.
“If I’m going to shift everywhere, everywhere includes nowhere, and now I’m shifting nowhere. I’ve gone from shifting left to shifting right and starting left, to shifting everywhere to shifting nowhere. It doesn’t actually mean anything anymore. It’s become a mumbo jumbo.”
—Chris Romeo
Full-lifecycle AppSec and shared responsibility are key
Security teams can’t simply shift AppSec work to developers or the DevOps team. While the premise that an early-in-the-SDLC scan of code is going to totally eliminate flaws before they get to production is flawed, the idea of getting security involved earlier in the lifecycle still has legitimacy.
Many in the industry are urging organizations to stick with shift left — but not to use it as a substitute for a comprehensive AppSec strategy. Full-lifecycle AppSec acknowledges that security oversight needs to be shared by different security stakeholders — and that it doesn’t stop once software is released.
Considering the cyclical and continuous nature of software development and the realities of code dependencies and microservices architectures, this is especially important, said Josh Knox, senior cybersecurity technologist for ReversingLabs. Software and associated infrastructure must be comprehensively tested and monitored. Failing to account for the fact that weaknesses crop up post-release all the time will lead to code rot, Knox warned.
“If I’m going to run my code through testing and lock the versions of my dependencies down, ... if somebody isn’t going back to find that several CVEs have come out around those packages, I’m going to keep right on cooking and making features.”
—Josh Knox
Part of full-lifecycle AppSec is that it needs to also include SecOps, said SheHacksPurple's Janca:
“We focus on all the things until go-live, but operational security for software is something that I see this huge hole in. And we must include that, even after the release.”
