How to “shift left” with application security tools, and how not to

by Charlie Klein on January 30, 2019

Organizations are starting to shift left to save time and money. But it’s critical they choose the right application security tools to support developers.

The “shift left” movement has gained traction as a strategy for finding and removing software vulnerabilities without throwing a wrench in the application development process. The idea is that it’s faster and cheaper to find vulnerabilities early in the software development life cycle (SDLC). The earlier development teams find vulnerabilities, the less rework they’ll have to do later. For this reason, many organizations are making their developers responsible for application security.

The key challenge of shifting left: Finding the right AppSec tools

Organizations hoping to shift left often adopt application security tools to scan code for security weaknesses. It’s logical to use an application security solution to find security issues early in the SDLC. But it’s not always practical for chronically overburdened and understaffed development teams.

Many application security tools generate a paralyzing amount of noise. As a result, developers have to spend time they don’t have separating false positives from real security weaknesses. Other tools require manual, tedious tasks to initiate scans that take too long. This process disturbs the natural flow of development. To put it simply, these tools can be annoying. And “annoying” can quickly turn into “infuriating” when the security review process delays deadlines.

Sponsorships Available

This raises serious questions about the impact application security tools have in organizations that want to shift left. The point of adopting these solutions is to remove exploitable software vulnerabilities at the application layer. But if they work against the goals of developers, how can we expect those developers to use them? The answer is, we can’t.

The impact of application security tools will ultimately depend on whether they are embraced by their users: the developers. In other words, if developers don’t use a tool, it won’t improve their organization’s security posture. To maximize their impact on software security, application security solutions must support developers and their goals.

How application security tools can support developers

Most developers have the common goal of producing secure, functional code within a deadline. To ensure security and functionality, they typically perform some sort of code review process to debug their code.

Debugging code is not among the hopes and dreams of most developers. Plus, lengthy debugging sessions can delay projects. So application security tools should help developers debug their code faster than if they were to do it manually. These tools should boost productivity and help developers hit their deadlines. This gives developers a real incentive to use the tool to remove software vulnerabilities. When developers embrace application security tools as a productivity solution, those tools are far more likely to have a material impact on vulnerability remediation.

In the end, application security tools should reduce the amount of time it takes for developers to debug their code. But this is no easy task. To help developers produce secure, functional software on time, these solutions must:

Integrate into daily developer workflows. They shouldn’t interrupt development processes geared toward hitting the next deadline.
Produce accurate and actionable results. That way, developers can fix vulnerabilities quickly once they’re identified.

Those hoping to shift application security left in the SDLC should find automated solutions that support the workflows, timelines, and goals of developers. When developers want to use an application security tool, development and security leaders can be sure that tool is having a real, tangible impact on their security posture.

Shift left with the right AppSec tools