|
|
|
There is evidence that compilation-based code analysis tools negatively impact risk mitigation efforts. As Gartner analyst Neil MacDonald observed, “we’ve talked with a number of clients that purchased a [static analysis] tool which later becomes expensive “shelfware” or where the project was halted after delivering mixed results.”1 Mr. MacDonald correctly singles out poor security process as an obstacle—but there are serious technical factors that contribute to the “shelfware” problem. A key, overlooked bottleneck comes from the compiler based approach. Getting the code into a state where it can be compiled and linked is not an easy task. How does the need for compilation negatively impact the stakeholders who rely on code analysis?
Executive Summary
Secure software development has become a priority for all organizations whether they build their own software or outsource. And code analysis is becoming the de facto choice to introduce secure development as well as measure inherent software risk.
Many assume that code analysis requires code compilation as a prerequisite. Today, all major static code analyzers are built on this assumption and only scan post compilation—requiring buildable code. The reliance on compilation has major and negative implications for all stake holders: developers, auditors, CISOs, as well as the organizations that hope to build a secure development lifecycle (SDLC). Historically, static code analysis required a complete and buildable project to run against, which made the logical place to do the analysis at the build server and in-line with the entire build process. The “buildable” requirement also forced the execution of the scan nearer the end of the development process, making security repairs to code more expensive and greatly reducing any benefits.
Click here for the full article
|
|