Posted by Charlie Klein on August 13, 2018
This is the first post in a three-part series on how you can maximize the impact of a static analysis solution by supporting developers and their goals.
Application security responsibilities are shifting to the developer as organizations look to produce secure, high-quality software at a competitive pace. Because of their IDE plugins, static application security testing (SAST), a.k.a. static analysis, tools are an intuitive solution for developers to find security weaknesses and quality defects as they code.
However, even though SAST tools scan code for flaws, that doesn’t mean developers use SAST results to improve application security. In fact, studies have shown that developers only address around 10% of SAST warnings during code reviews. Many attempts to integrate static analysis into software development organizations fail. In these cases, it is introduced to developers but doesn’t play a significant role in the way they identify and fix flaws.
While organizations adopt static analysis to produce high-quality and secure code, the likelihood of achieving that task ultimately depends on the users of the SAST tool: the developers.
While organizations adopt static analysis to produce high-quality and secure code, the likelihood of achieving that task ultimately depends on the users of the SAST tool: the developers. Static analysis is more likely to have a positive impact on application security when developers both benefit from and enjoy using SAST tools. For this reason, static analysis projects should be aligned with the goals of developers, rather than adding another checkbox to the developer’s to-do list.
There are many ways static analysis can either support or work against the goals of developers. Whether developers enjoy using static analysis has significant consequences for the impact, and therefore ROI, of SAST tools.
Release deadlines continue to get tighter for developers in response to business pressures to reduce time-to-market. Most, if not all, development teams share a common goal of producing secure, functional code within the deadline of the next product release. Static analysis can support that goal by reducing the time and effort needed to debug code—potentially becoming an essential element of the SDLC.
Workflow integration and results are two crucial elements of static analysis that might sway a developer to embrace or ignore a given SAST tool.
Security testing can disrupt DevOps initiatives, which encourage continuous, iterative development. However, static analysis that is designed to integrate seamlessly into unique development workflows can simplify debugging efforts.
The development workflow is the set of tasks a development team executes to deliver functional software. Static analysis that integrates seamlessly into the workflow will have a minimal impact on the natural flow of software production. By contrast, SAST tools that cause developers to deviate from their usual tasks can be time-consuming, which may work against the goal of delivering code quickly. In fact, poor workflow integration can be a key barrier to adoption.
Accounts from the Google SAST team reflect on their strategies to encourage developers to embrace static analysis. They describe methods to make static analysis as quick and easy as possible to drive adoption. Similarly, developer surveys suggest SAST tools are viewed more favorably when they don’t require developers to change their normal processes.
Integrating SAST can be a challenge, given the variety of workflows developers may use to produce software. To accommodate varying development processes, SAST tools should empower developers to tailor their analyses to fit their changing needs. While some developers may want to perform deep analyses overnight, others may prefer to identify flaws as they code. When static analysis is flexible, developers can integrate the debugging process into their unique workflows.
Like workflow integration, the results of static analysis also affect whether developers can achieve their goals. SAST tools can help developers produce software at the security and quality standards demanded by customers. However, results that are confusing or inaccurate can throw a wrench in the debugging process—which can be frustrating and counterproductive. For developers to benefit from SAST tools, static analysis results must be:
With relevant, accurate, and actionable information on weaknesses and defects in their code, SAST tools can support development teams and their goals by helping them deliver secure, functional software, without slowing down development.
A developer-centric approach to implementing static analysis must support developers’ goals, including, in the context of software security and quality, debugging their code quickly. By integrating into unique development workflows and producing actionable results, static analysis can help developers do just that.
Static analysis tools are often portrayed as security or quality assurance solutions—after all, they do identify security weaknesses and quality defects. However, this approach may neglect the needs of developers, who ultimately determine whether a SAST solution will become shelfware or a key component of the SDLC. Static analysis has the greatest impact on application security when it is also designed as a solution for developer productivity.
Get the latest Software Integrity news, thought leadership, and more.