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.
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.
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.
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:
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.
As a Product Marketing/Business Rotational Program Associate at Synopsys, Charlie will rotate through the sales, marketing, sales operations, and finance departments four months at a time. He joined Black Duck Software in July, before Black Duck Software was acquired by Synopsys. During his time in sales and marketing, Charlie has researched and learned about the importance of open source risk management—especially pertaining to container security and secure DevOps practices. While in marketing, Charlie has been helping with the launch of OpsSight, a product designed for IT Operations and Infrastructure teams hoping to automate security practices in the production environment. He holds a B.A. in Political Economy from Bates College.