Don’t Shift Left, Expand

The last few years the biggest buzzword was shifting left. You have seen it everywhere. The concept is pretty simple when you think about the evolution of application security. We started out with a huge focus on penetration testing and providing a report back to the development team. The majority of organizations didn’t have application security teams, and if they did, they were usually pretty small and limited in function.

This method of app security was easy because it was in a time where security and engineering were pretty much separate. They worked in their own silos and this was an easy solution. We develop, you test, we fix. Thanks to this, there is an entire industry built around security testing. While testing helps us secure our applications (well, if we actually mitigate the findings), It typically occurs after we have released our code. This is very costly and a bit late to the game. Sure, some issues are pretty easy to remediate, but there are others that may require architectural changes.

Imagine the cost of those types of changes after the app is written? I can validate that when the designs change after deployment it can be a true nightmare to fix.

The good news, application development is maturing. It is changing for the better. Application security teams are starting to exist within organizations and we have expanded our capabilities from just testing and running automated tools to being much more integrated with the development process. As we take on more of these challenges, we keep saying shift left, but what does that mean?

When we look at the SDLC, it is shown as linear. We start with design, go through coding and testing, and release it in the wild. As mentioned earlier, a lot of focus was on the testing section of the SDLC. Shifting left in the process is putting a focus on the earlier stages.

For example, having tools that integrate in the development phase to quickly identify vulnerable code before it is even checked in. Threat modeling in the design phase is another key component to identifying potential risks before we even start any coding.

What I don’t like about shifting left is that it indicates that we are leaving the right to work on different phases. This is wildly inaccurate.

First, we are not shifting, but more of an expansion. I am not going to stop the testing and other things I have been doing, rather I am expanding my capabilities to include more of the process. Second, left assumes that development is linear and in most cases, this is not the case. Development is more of a continous cycle that just keeps revolving around. While the typical SDLC stops at release, when the Secure SDLC came out it added in response after release which of course then loops back around to the development cycle again to update/release new features.

It doesn’t matter the terminology you use, as most of it is all just buzz words for marketing purposes. There is a need for security considerations throughout the entire application lifecycle. The important part is are you putting security processes in place where they make sense. We know we can’t do it all at once, so being smart about where you put things matters. Don’t get caught up in the hype and the distractions it brings. In either case, if you are already doing something, don’t stop doing it to start doing something else. Look to see how you can add to your coverage, not move it.