Shifting left in the realm of application security sounds great on paper, but can easily become a nightmare when trying to put it into practice. The premise of shift left has the potential to deliver enormous benefits by making it easier to detect and remediate risks early in the software delivery lifecycle – which not only saves time, but also reduces the cost of fixing bugs.
Inefficient security tools can also inundate development and security teams with a large volume of low-value alerts or false-positives, making it difficult to prioritize which risks actually matter.
But it doesn’t have to be this way and this article explains how to achieve these goals by implementing a shift-left application security strategy correctly.
Before looking at why shifting application security left is challenging, let's look at why organizations typically embrace shift left strategies.
When done right, shift left security can deliver a variety of great benefits:
In short, shift left security has the potential to improve security outcomes while also reducing the time, toil and money that organizations devote to application security.
Sadly, the way many organizations go about implementing shift left security often creates more problems than the practice solves. Here's why many shift left programs go awry.
Shifting security left requires more than just adding some security processes to your software delivery lifecycle. You must also change your security culture. You need to adopt a security-centric mentality and become willing to prioritize security alongside delivery speed and application functionality.
Unfortunately, this is a hard shift for many organizations to make. Some teams continue to make security a second-tier consideration in practice, even though they might talk about it more.
Developers are already busy in a world where they are expected to deliver code continuously. When you ask them to help respond to a slew of security alerts that pop up early in the development process, their jobs become even harder.
Obviously, detecting security issues early is a good thing. But problems arise when shift left security processes result in a large number of alerts that are either false positives, or that don't reflect risks that are serious enough for developers to fix right away. Low-value alerts become distractions for developers, leading to slowdowns in software delivery operations without a corresponding increase in application security posture management.
Shift left application security tools and processes are typically designed primarily for security teams, not for developers. The alerts they generate aren't always easy for developers to interpret; programmers may struggle, for example, to figure out which lines of code they actually need to fix to remediate a security vulnerability.
This challenge exacerbates the issue of having too many alerts to deal with. Shift left security has a tendency not only to leave developers drowning in alerts, but even worse, they may not know how to make sense of those alerts.
The key is in Application Security Posture Management (ASPM). ASPM means continuously assessing, maintaining and improving application security. It's about identifying risks, implementing policies and procedures, monitoring controls and responding to incidents to ensure that applications are secure throughout their lifecycle.
Put another way, ASPM involves transforming shift left security from a practice where teams merely generate security alerts early in the development process, to one where they holistically manage all aspects of security starting early in the SDLC.
This approach enables better collaboration between security and development teams because it leads to actionable guidance for the latter. It provides developers with crisp evidence that helps them determine which alerts they need to respond to, as well as how to respond to them.
Ultimately, ASPM ensures security teams and development help each other, instead of working at cross purposes. Rather than simply creating more work for developers by asking them to handle security risks that they are not well positioned to address, ASPM means that security teams can actually collaborate with developers to remediate risks without slowing down software delivery.
We're all for shift left security, but we think the typical organization needs to rethink its approach to shifting application security left. We envision a world where there is a balanced approach to security, using the concept of application security posture management. This is because ASPM is a much more visual concept which enables teams to see, and get a prioritized risk overview of all security issues facing applications and microservices. This includes a holistic overview of all AppSec alerts and not only those of a specific type - for example SAST or SCA.
We designed Backslash Security to help bring about this future. By coupling intelligent alerts with actionable guidance, Backslash represents a new breed of AppSec tool that AppSec teams and developers teams alike can love – which is exactly what it takes to move the needle when it comes to shift left security.
Yossi Pik is the CTO and co-founder of Backslash Security