This is the second post in a three-part series on how you can maximize the impact of a static analysis solution by supporting developers and their goals.
As discussed in the previous blog post, static analysis is more likely to have a significant impact on application security when it supports the goals of developers, rather than giving them another task to complete. While static analysis is generally viewed as a security solution, SAST tools are typically used by developers—so the impact of static analysis on application security depends on whether developers embrace SAST tools.
Organizations ask a lot from their developers; they demand not only increasingly complex software but also tighter deadlines. For this reason, developers are unlikely to embrace SAST tools that disrupt development workflows. Rather, they prefer static analysis with a minimal impact on their normal workflow—which informs them about the quality and security of their code without distracting them.
Google’s static analysis implementation demonstrates the importance of convenient development workflow integration. Initial attempts to integrate static analysis into Google’s development process failed because their SAST tool reported information on a separate dashboard. Developers felt that switching between the dashboard and their IDEs was a hassle, so they dismissed static analysis. In response, the Google SAST team created multiple integration points within the SDLC—giving developers the flexibility to debug where it was easiest for them. This simple change significantly influenced its adoption.
Ultimately, Google’s developers embraced static analysis because it made debugging efforts easier when integrated into their existing development workflows. As Google’s static analysis team said, “For a static analysis project to succeed, developers must feel they benefit from and enjoy using it.”
“For a static analysis project to succeed, developers must feel they benefit from and enjoy using it.”—Google’s static analysis team
Coverity by Synopsys lets developers scan their code for security weaknesses and quality defects without disrupting their normal workflow. By enabling developers to tailor their analyses and by automating remediation efforts, Coverity makes the debugging process easier, and therefore faster.
Developers using Coverity can determine the speed and depth of their analyses by choosing between fast desktop, incremental, or full analysis modes. Fast desktop and incremental analyses can help developers find flaws as they code—where they are easiest to find and cheapest to fix. Coverity’s full analysis mode integrates with build/CI tools and fails the build if flaws violate a security or quality policy. DevOps teams have the control to manage their analyses depending on their changing needs.
Given the variation of workflows, there is no one-size-fits-all approach to static analysis. Developers using Coverity can use whichever strategy best integrates with their existing workflow—enabling them to debug their code quickly.
As Google’s SAST team states, finding bugs is the easy part. The real challenge is encouraging time-strapped developers to fix bugs and defects, which requires time and effort. If static analysis solutions do not allow for quick debugging of code, they are unlikely to be embraced by developers or have a positive impact on application security.
To expedite remediation efforts, Coverity automatically assigns security weaknesses and quality defects to the developers responsible. A long list of code issues can cause stress and confusion, but with Coverity’s auto-assignment function, development teams gain visibility into who is responsible for specific problems. When static analysis is designed to make remediation easy, fixing flaws is faster and more effective.
Finding weaknesses and defects in code is generally not among the hopes and dreams of developers. Security testing tools that are time-consuming or disrupting are, understandably, likely to reinforce any negative sentiments developers may have about the security review process—which is counterproductive for application security. However, when static analysis integrates into existing workflows, it can support developers by decreasing the time it takes to debug code.
Developers using Coverity don’t have to make dramatic changes to their workflow to accommodate security testing. With tailored analyses and automated remediation efforts, Coverity’s integration into development workflows makes it easy to use. And when static analysis is easy to use, developers can spend more time writing code, rather than fixing it.