The Limits of Shift-Left: What’s Next for Developer Security

Shift left is experiencing a bit of a backlash, not just from developers but security professionals as well.

Shift left is the practice of pushing security concerns to the code level, which means software developers bear more responsibility for it. The goal is to find and stop vulnerabilities as soon as possible in the development practice.

But there are problems with the approach, as Peter Klimek, director of technology with the office of the CTO at security company Imperva, explained in this episode of The New Stack Makers. Klimek talked with The New Stack reporter Loraine Lawson about why there’s a shift-left backlash.

“When I started going in querying and polling various CISOs in the organizations, I found that the pushback wasn’t just limited to developers, it was also security professionals that were starting to push back on it,” Klimek said.

Why? Some organizations may be reaching the end of what can be achieved with shift left, he said. Also, for most organizations, the problem isn’t necessarily finding vulnerabilities but finding the time to fix them, he added.

Another factor at play: Security attacks themselves are shifting away from targeting dependencies to targeting business logic vulnerabilities. Shift left tools are good at identifying the former, but the later often involve targeting authorizations vulnerabilities that can’t be addressed at the code left.

“Authorization decisions within an application are usually closely tied to the business logic of the application, and by them being tied to the business logic, this makes it very hard for you to use shift left tooling to identify those vulnerabilities earlier in production,” Klimek told The New Stack. “Similarly, we know that there’s lots of vulnerabilities and attack vectors out there that aren’t even necessarily targeting your code. They’re targeting your users.”

This is a major security challenge: More than 700 million password pairs, passwords and usernames were leaked onto the dark web last year alone, he added. This makes the frontend a frontline for security vulnerabilities, especially with API development and cart attacks, which basically act like a digital skimmer similar to credit card skimmers, he said.

“What we’re looking for here is usually the security of the dependencies that JavaScript developers and frontend developers are pulling into their code, as well as the interaction with third-party libraries and frameworks that they have on there,” he’s said. “They should also be part of the threat modeling exercises because they’re no longer immune from it.”

Development teams and security teams will need to work in tandem to improve security, he added. He explained the importance of using DORA metrics with both development teams and security teams to determine where security efforts are working and where they are not.

“The peak shift left for me is really this point where the additional tooling that you’re adding to your software development lifecycle is really doing more harm than good at this point,” Klimek said. “For some organizations, they certainly haven’t hit that. But for others, they’re getting to that point, or they’ve already gotten to that point.”

Ultimately DORA metrics can help determine if something is too onerous for the development team and what the data is in terms of slowing down the production pipeline, he said. In the podcast, he drills down into what that means.

“One of the things that I strongly advocate to security professionals that may be listening to this is that the DORA metrics are actually really positive and beneficial for security teams as well,” he said.

Check out other episodes in this series with Imperva:

Why Your APIs Aren’t Safe — and What to Do about It

What Developers Need to Know about Business Logic Attacks