Shift Left… it’s a term used almost ubiquitously across application security by both security practitioners implementing programs, regardless of scale, as well as just about every vendor selling an application security solution.

The idea that it’s faster, cheaper, and often easier to fix a security flaw when the code is being created (as opposed to later in the software development lifecycle (SDLC)) is widely accepted within the AppSec community. It only makes sense that we’ve moved towards using tools that identify risks earlier in the development process so developers can correct those issues immediately. But if this revolutionary philosophical change is being adopted en masse, why aren’t we seeing a giant reduction in application security issues across the threat spectrum?

Background

The answer to this is largely scale. Scale in both the amount of code being created on an ongoing basis and the enormous scale of existing and new security issues that need to be addressed within a typical application. What shift left doesn’t take into consideration is that while modern-day application security testing (AST) tools are really, really good at finding issues, that frequently results in hundreds or thousands of identified issues. In large organizations, this number can easily jump to hundreds of thousands or sometimes millions of vulnerabilities identified across the wider application portfolio. Just triaging that many issues is extremely time-consuming, let alone actually going through and fixing each one.

This is why having context around the issue, application, infrastructure, and runtime environment is so important to successfully implementing shift left. While this sounds great in theory, gathering all of this context and making it easily digestible is a significant task in and of itself. But this is the main problem that needs to be solved for any AppSec program to mature beyond simply scanning for vulnerabilities and amassing security debt.

Fortunately, the market also understands that solving this problem is critical – which is why we’ve seen an explosion of new companies entering the recently named Application Security Posture Management (ASPM) space. One of the main focuses for tools in this category is a holistic understanding of application risk (code, OSS, infrastructure, build tooling, etc) and pairing it with relevant prioritization information, which allows for more intelligent triage and remediation of critical issues. But more on this later, I promise…

But for now, let’s take a quick step back and talk about what “Shift Left” means, what the original goals were, and what it actually looks like now. If this is the first time you’re hearing the term “shift left,” all it really means is shifting security further left towards the developer in the SDLC. This could mean running scans for open-source vulnerabilities in a developer’s coding interface or IDE, introducing security testing on any new code created before it gets merged, or any of a number of other technical implementations that allow for security testing to be implemented as close to the developer creating the code as possible.

The goal here is largely that developers will see the alerts as they are creating code so that they can take action immediately. This not only identifies security issues before they hit production but leads to faster fixes since the developer is already thinking about that piece of code and how it works. For companies creating code at a large scale, this means fewer security issues hitting production while allowing for increased productivity and agility across the development and security teams.

Absolute win/win, right!?!

Well, yes, for vendors selling shift-left solutions, that seems obvious. However, security debt continues to grow for most organizations, despite many of the shift left solutions and best practices being implemented. When looking at something like Veracode’s State of Software Security report from 2023, you can see that even organizations that have implemented good practices still accumulate security debt that continues to accrue the older the application is. If shift left works, why are we still accumulating debt?

As mentioned earlier, it’s primarily a scale issue. There are just too many issues being found that need to be triaged and remediated without enough time or people to fix all of them. Developers already live in complex environments with diverse tool sets and technologies that they have to use and master on a regular basis. Introducing a bunch of new security tools into the development process just creates additional alert and tool fatigue, confusion, and extra work.

What we see instead of development velocity increasing and security debt decreasing is that companies usually notice their security debt increasing because developers are ignoring the thousands of alerts, or they see velocity take a nosedive while security debt levels out or decreases because too many development cycles are being devoted to closing out low priority issues because guardrails that can’t be bypassed.

The happy medium we’re all chasing ends up being elusive because developers aren’t equipped to triage which of the risks they should focus on and which to ignore, which would allow them to better balance productivity while minimizing risk. They usually aren’t security experts, nor should they have to be, and often, they work on small pieces of much larger projects without understanding the entirety of the scope or impact it has on the business. Questions like “Is this vulnerability in a production environment?”, “Is there some other mitigation in place elsewhere in the application?” or “Does this issue exist in an application that deals with sensitive data?” are all important to answer when deciding whether to accept or remediate a specific risk. It’s this context that’s often missing when asking developers to decide which of the hundreds of issues they need to fix first. The most effective way to shift left is through better triage and prioritization so that key risks and issues are identified and shifted to the developer earlier in the process while making sure they aren’t inundated with unnecessary or irrelevant alerts.

Aspects of this are the mission of just about every single company vying for space in Gartner’s newly introduced category—Application Security Posture Management (ASPM). While every ASPM offering varies in approach, they all share a common goal, which is to automate the consolidation of vulnerabilities, assess their potential impact based on risk to the organization, and triage accordingly to shift security left with the context needed for faster remediation. In the Gartner Innovation Insight for Application Security Posture Management report, they emphasize the value of having an ASPM tool to help automate risk assessment and thereby improve “Shift Left” practices in organizations using them. Saying, “These solutions enable developers to distinguish critical security issues from the noise and facilitate early remediation.”

As mentioned earlier, almost every company in the ASPM space is currently tackling this problem in a different way. Some are looking deeply at the code itself to alert on every new change happening (this is obviously very process intensive and often generates a bunch of new noise that needs to be sorted through or tuned out), some are purely working on vulnerability management from a consolidation and correlation standpoint (this is a good and necessary approach, but often overlooks important aspects like development and production environment context), and others are trying to address the problem through production runtime analysis (great context to have, but misses out on important data from the build and development environments, and lacks important information about where in the code to actually remediate).

At Legit Security, we believe in taking a more holistic approach that delivers a better understanding of risk across the entire software development lifecycle, with the visibility and context that allows you to understand, prioritize, and remediate quickly without interrupting product innovation. We do this by integrating into the development source control management system the different CI/CD build tools (such as Jenkins or ADO), as well as production environments, to give you complete visibility into all the risks across your entire development and production environment. This lets you accurately prioritize issues and quickly create custom policies that match your organization’s risk profile. Legit allows you to easily find all the issues in your environment that are in production and customer-facing, that touch things like sensitive data, or that might be caused by a malicious developer based on anomalous behavior detection.

“Shift Left” as both a philosophy and practice in AppSec is a game-changer for any org trying to secure software at scale, and real statistics confirm its cost-saving benefits when executed correctly. The key is executing correctly! ASPM, as a rising category in Application Security, offers a powerful toolset to help organizations execute and make shift left successful within their application development processes. Legit, with its differentiated approach, leads the charge in enabling developers to shift left with context on all issues found across the entirety of the software development factory with context from the application, build environment, and production environments for a truly complete code to cloud solution. As organizations strive for continued competitive advantage in the software development landscape, embracing ASPM and leveraging a solution like the Legit Platform is the way forward to decreasing security debt across your portfolio while also keeping you developers developing at maximum production velocity.

To learn more about how Legit Security can help, Book a Demo to see the Legit Security platform in action.  

*** This is a Security Bloggers Network syndicated blog from Legit Security Blog authored by Joe Nicastro. Read the original post at: https://www.legitsecurity.com/blog/rethinking-shift-left