Considered harmful: Blindly shifting left

The motivation behind “shift left” security is sound. 

When the security community talks about shift left, we are often thinking in terms of shifting security activities earlier in the software development process. The rationale: The earlier in the Software Development Life Cycle (SDLC) that you eliminate the risk, the lower the cost to fix the issues, and the shorter the time that your application is exposed. 

This emphasizes prevention as opposed to detection and response. Why that’s preferable: The vast majority of successful attacks go undetected at the time. Even the rare organization that maintains a huge investment in gathering system telemetry can rarely do better than figure out what happened after the damage has already been done. Most of the time, organizations first learn they’ve been breached when they receive a ransom notice or learn that their customers’ credit cards are up for sale on the dark web.

However, the real magic from shift left occurs when you stop thinking of it as merely shifting activities, but rather shifting ownership. Let me illustrate the difference.

The magic of shifting ownership

When a security incident is in progress, instead of just having downstream security specialists be involved, insist that a representative of the upstream development team be involved in the response. Imagine a developer getting called in all weekend to deal with such an incident. She walks into her team’s planning meeting on Monday and says, “If we had just had this one extra piece of information in the logs and this one switch in the product, I could have been in and out of there in five minutes rather than having lost an entire weekend. Let’s add those to the product this next iteration.”

The old-timer on the team points out, “You know, Security has been asking for those two things for years now.”

Another teammate says, “That’s great. It’ll help with detection and response, but I’ve been thinking, if we added CSP [Content-Security-Policy HTTP response] headers, we could prevent entire classes of attacks like this. Let’s do that next.”

This is what happens when you optimize for the whole rather than just your little part of a big process. Shift left fails when you think of it as shifting the activities and succeeds when you break down silos of responsibility. When Security owns the problem of security, the best you get is reactive and bolt-on fixes and/or requests of the upstream developers that are largely ignored. However, by shifting ownership of the problem of security to the left, more effective solutions are proposed, along with motivation to implement them.

And here’s what can go wrong

Those are a lot of benefits. Add it all up, and we can all agree that shift left is a powerful strategy. However, as the old saying goes, “Execution eats strategy for breakfast.”

Arbitrarily shifting AppSec activities using the same tools that Security now uses to Development without adapting — or in some cases wholesale replacing — those activities and tools to the way developers want to work (DevOps) is a recipe for frustration and false starts.

Additionally, it’s possible to shift too far left and/or too fast. Furthermore, not all applications are the same. Maintenance-mode applications, for instance, often don’t have mature development resources to shift left to.

Instead of mindlessly shifting left, we need to “shift smart!”

Don’t just shift left. Shift smart. 

Larman’s laws of organizational behavior state that any change initiative will be redefined back to the status quo by the incumbents who will be disrupted by that change. That’s what’s happened to the phrase shift left and why I’m now using a new term: shift smart. The funny thing is that the people Larman is talking about never realize that’s what they’re doing. So, while I could continue elaborating on what I mean when I say shift smart, my words are likely to be redefined on the fly by the very folks whose minds I’m trying to change. Rather, I need a bigger shakeup first.

That’s why I’ve decided to launch a series entitled “Considered Harmful.” I haven’t quite decided on every post, but it will include controversial titles such as:

• Considered Harmful: Finding vulnerabilities 
• Considered Harmful: SLAs
• Considered Harmful: Sharing SBOMs
• Considered Harmful: Kill-Chain Analysis 
• Considered Harmful: AppSec policy 
• Considered Harmful: SAST and DAST 

I’ll measure the success of the series by how vehemently you disagree with the statements above, but I ask you to first give me a chance to explain what I mean rather than react now.

Read more:

• Shift smart instead of following shift-left fairy tales
• Blowing up DevOps bottlenecks with pull requests
• Secure your app process from development to deployment: Fireside chat
• How to empower dev & security teams with acclaimed author Derek Fisher
• How an American Financial Technology Company Embeds Application Security (podcast)