Why You Should Shift Left Your Security

Are you tired of running after application owners to patch their vulnerable apps? Fixing vulnerable code in production takes months? Shift Left your security and you will find these issues less and less.

In this post we’ll learn what is the shift left security approach and how it would not only improve the security posture of your applications but also make it easier for you to do your job, be it a security architect or a software developer.

What is Shift Left Security

First we need to understand what’s left and what’s right. In the Software Development Lifecycle (as depicted in the diagram below) Left is the side where you plan, code, build and test your software, while on the right you release, deploy, operator and monitor it. In simple words, left is the development stages, right is the production stages. Shift left security means moving the security to the very first stages of the software development lifecycle (SDLC).

With Shift left, Vulnerabilities and Misconfiguration scanning that traditionally run when the software is already deployed in production, are now running at the Code and Build stages (at the very left of the diagram above).

But why is it so important to shift left your security? What benefits do we get from shifting left, and what are the drawbacks?

Why Do We Need to Shift Left

Now that we understand what Shift Left is, let’s see why it is so critical for the security posture of your operation.

With the traditional security approach, vulnerabilities are found at the very end of the software development lifecycle, be it in pre-production environments at best case, or in production at the worst case. This approach puts your operation at risk - your data and your customers’ data is at risk, since vulnerabilities exist in production. And to fix this risk, you have to notify the application owner, so that the development team will find the time to have the codebase fixed, then built, tested and deployed. This can take time, sometimes between weeks to months, and during that time your operation is vulnerable.

If you shift left your security, a significant number of vulnerabilities will not reach your production environment in the first place. They won’t even reach the codebase. Instead, they will be found and fixed early in the software development lifecycle.

With Shift Left, you don’t wait for the issues to arise to fix them, you prevent them before they become issues. Because what’s a better way to fix a problem than to prevent it?

Moreover, the ownership on these issues also shifts left, and becomes the software development team’s. With that approach, the software that is deployed at production has significantly less vulnerabilities and misconfigurations.

How do we Shift Left

So how do you shift your security left? What tools are there, and how should you use them? Below is a short list of the types of tools you can use to Shift Left your security, starting from the leftmost side and going right:

• Static Application Security Testing (SAST) - also known as Static Code Analysis, statically scans the source code of the application to detect known vulnerabilities. This type of scanning does not require to compile or run the code, and so software developers can run these scans from within their Integrated Development Environment (IDE) while they’re writing the code, allowing a very short feedback loop. For more information check out our post on SAST...
• Dependency Scanning - scans the source code dependencies to detect known vulnerabilities in libraries, be it the programming language itself or open source libraries referenced by the source code. This type of scans can also be run by the software developers from within their IDE, allowing them to fix issues at development stages. For more information see our post on Dependency Scanning.
• Dynamic Application Security Testing (DAST) - as opposed to SAST which scans the application from the inside, DAST scans the application from the outside looking for known vulnerabilities according to predefined patterns. DAST uses the application’s public facing interfaces to perform the scan, and so It requires the scanned application to be compiled and run. Therefore, these tools typically run in pre-production environments.
• Interactive Application Security Testing (IAST) - combines the strengths of SAST and DAST, IAST runs as an agent from within the application and assesses both the application source code and the connections of the application to detect vulnerabilities.
• Runtime Application Self Protection (RASP) - runs as an agent from within the application itself, in order to detect and possibly block attacks at runtime. RASP analyzes incoming and outgoing connections of the application with their context to identify attacks when they happen.

A good shift left strategy would be to implement few of the above tools, as each type can detect different kinds of vulnerabilities - issues that can be tracked down from the source code, not necessarily can be detected by communicating with the application from outside, and vice versa. Before choosing what tools to run, you need to think what can suit best your needs and how can each tool integrate with your software development pipeline. To get into the details of each and every tool, you can check out this exhaustive list of AST tools published by OWASP long ago, as well as to get a benchmark application which you can use for comparing the different tools.

But is it enough to Shift Left?

Although it is highly recommended to shift left your security, Shift Left approach cannot provide the comprehensive and complete security strategy for your operation. Such a strategy will aspire to detect and prevent vulnerabilities as soon as possible in the software development lifecycle, but at the same time will make sure to scan the production environment to close the loop on vulnerabilities that eventually got in, as well as monitor activity to detect and respond to attacks when they happen.