Why Shifting Left Is a Pipedream for Application Security
July 19, 2023

Jacob Garrison

Detecting vulnerabilities early on in the software development life cycle has advantages, but in the real world, "shifting left" has many limitations.

Three crucial factors hinder the effectiveness of shifting left: test coverage, business context, and the disparity between production and pre-production environments. By critically examining and addressing these limitations, we can establish a more proactive approach to application security — ensuring that systems remain resilient by detecting vulnerabilities early on.

Let's dive in.

Limitation 1: Test Coverage

Some organizations decide to run application security testing tools on every piece of code. But there are multiple drawbacks to this approach.

Enterprises with large code bases suffer from test length. By the time tests finish running, engineers have switched to the next task and the scrum leader must decide if the security risks surfaced must be fixed immediately. Teams can avoid this by telling engineers they can only switch tasks once security tests are complete, but that impacts development velocity.

One solution is to identify changes in the code base and run tests only on the deltas to ensure no new vulnerabilities are added. This works well, but typically requires the enterprise to dedicate a large number of engineering hours to develop that technology around its existing security tooling. Another solution is to tune down security testing tools to increase speed and reduce the number of alerts they produce. With fewer alerts, developers are more likely to fix them, but other vulnerabilities are making their way into production.

Microservices are the modern alternative to large code bases. With this approach, enterprises own hundreds or thousands of code repositories. Ensuring that security tools are configured for every single repository or CI/CD pipeline is challenging, which is where DevSecOps comes in. Organizations have entire teams dedicated to ensuring all new code is checked for security, but putting those guardrails in place doesn't happen overnight. And even with them in place, teams still need to worry about shadow IT — or bypassing proper channels for the sake of speed or getting a system back online — which has existed as long as security.

Limitation 2: Business Context

Business context is crucial in security, and one of the major considerations are false positives. A false positive is a security finding that, upon further investigation, is deemed not to actually pose a risk to the business. These ruin the trust between security and development teams.

But even if we assume all of our security findings are true findings, how do we prioritize which to fix and which to fix first? As it stands, organizations often use the Common Vulnerability Scoring System (CVSS), which gives a way to quantitatively measure risk but misses the bigger picture of the application. Most practitioners agree that using the application's architecture is a better way to prioritize risk, but it can be very hard to quantify.

If you can look at the architecture — its dependencies, data flows, business context, sensitivity of data, the blast radius of a breach — you can create a clearer picture of what needs to be prioritized by security and development teams. Then you can secure stakeholder buy-in by showing the vulnerabilities in business terms rather than an arbitrary list of CVSS scores.

The reason this is challenging in shift left is that code development is removed from the larger application that security tools aren't able to see a vulnerability and correlate it to where it lies within an application and the business at large. That lack of visibility is a key limitation of the shift left approach.

Limitation 3: Production vs Pre-Production

Shifting left focuses on pre-production, the environments where code is developed and tested. It's true that vulnerabilities are easier to fix early in the pipeline, so it definitely has its benefits, but it's impossible to measure the full risk in pre-production.

For example, why are security operation centers and SIEM tools focused on what's happening to their running applications? Because threat actors are attacking where there are valuable business assets and data: the production environments. If we can figure out which microservices are important, we can target those with our shift left tools. This works well for small businesses, who can focus on things like payment processors, but it tends to fall apart for large enterprises struggling to document where code lives, which code is live in production, and how that production environment is changing over time.

Without an application inventory and understanding of what is live today, it's difficult to prioritize what's impacting the business. Plus, applications morph as code compiles. When you shift left and focus on source code, you're ignoring things like configuration files and command line arguments that actually add or remove mitigating controls for an application through deployment. The way that you're prioritizing risk could become moot by the time the code reaches production.

In conclusion, it is imperative that organizations understand the limitations of shifting left, from test coverage to business context to the difference between production and pre-production environments. These considerations are important when designing an application security strategy and creating a comprehensive security program.

Jacob Garrison is a Security Researcher at Bionic
Share this

Industry News

December 06, 2023

ngrok unveiled its JavaScript and Python SDKs, enabling developers to programmatically serve their applications and manage traffic by embedding ingress with a single line of code.

December 06, 2023

Data Theorem introduced API Attack Path Visualization capabilities for the protection of APIs and the software supply chain.

December 05, 2023

Security Journey announced support for WCAG, SCIM and continued compliance with SOC2 Type 2, which are leading industry standards.

December 05, 2023

Vercel announced a new suite of features for its Developer Experience (DX) Platform, made for enterprise teams with large codebases.

December 04, 2023

Atlassian Corporation has completed the acquisition of Loom, a video messaging platform that helps users communicate through instantly shareable videos.

December 04, 2023

Orca Security announced that the Orca Cloud Security Platform has achieved the Amazon Web Services (AWS) Built-in Competency.

November 30, 2023

Parasoft, a global leader in automated software testing solutions, today announced complete support for MISRA C++ 2023 with the upcoming release of Parasoft C/C++test 2023.2.

November 30, 2023

Solo.io achieved the Amazon Elastic Kubernetes Service (Amazon EKS) Ready designation from Amazon Web Services (AWS).

November 29, 2023

CircleCI implemented a gen2 GPU resource class, leveraging Amazon Elastic Compute Cloud (Amazon EC2) G5 instances, offering the latest generation of NVIDIA GPUs and new images tailored for artificial intelligence/machine learning (AI/ML) workflows.

November 29, 2023

XM Cyber announced new capabilities that provide complete and continuous visibility into risks and vulnerabilities in Kubernetes environments.

November 29, 2023

PerfectScale has achieved the Amazon Elastic Kubernetes Service (Amazon EKS) Ready designation from Amazon Web Services (AWS).

November 28, 2023

BMC announced two new product innovations, BMC AMI DevX Code Insights and BMC AMI zAdviser Enterprise.

November 28, 2023

Rafay Systems announced the availability of the Rafay Cloud Automation Platform — the evolution of its Kubernetes Operations Platform — to enable platform teams to deliver automation and self-service capabilities to developers, data scientists and other cloud users.

November 28, 2023

Bitrise is integrating with Amazon Web Services (AWS) to provide compliance-conscious companies with greater access to CI/CD capabilities for mobile app development.

November 28, 2023

Armory announced a new unified declarative deployment capability for AWS Lambda.