DEVOPSdigest

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.