|
|
AS OF 7/20/2008 5:46PM EST
|
December 12, 2007 —
How do you convince an overworked developer to add another task to a long to-do list?
Source code analysis tool makers have sought to answer that question since they began selling software for finding security flaws a few years ago.
Recently, they have begun offering a new answer: Run the scan at build time instead of insisting developers do the job at their desktops. “The build server is a powerful place to be,” said Fortify chief scientist and co-founder Brian Chess. “You don’t want [developers] to tie up their personal workstations.” Incorporating source code analysis as part of nightly build helps eliminate issues that will surface later, added Ounce Labs senior vice president of product management Claudia Dent. And it makes the task “more palatable to the development team.”
Neither company—nor their competitors—suggested that running the scanners at build time is the sole solution for finding security flaws. All of them said security should be addressed at every stage of the development process. But the build time approach has gained attention as source code analysis tool makers contend with the fact that their offerings have not been well received by developers. The key objection, as reported earlier by SD Times, is that scans take too long and turn up too many false positives. Another barrier to adoption is that the art of secure coding is so new that most professional developers working today have not been trained in the practice, said IBM Watchfire director of security research Danny Allan.
IBM acquired Watchfire earlier this year. The company sells, among other offerings, a penetration testing tool, which assesses application security by simulating attacks a hacker might launch.
Chess raised the issue of running source code analysis at build time in “Secure Programming With Static Analysis,” a recently published book he co-authored with Jacob West (Addison-Wesley 2007). Dent is tackling the topic in a forthcoming white paper. And IBM also advanced the idea. In an October meeting with SD Times, IBM Rational program manager Ashok Reddy said source code analysis can be “cumbersome for developers.” So IBM is readying its Build Forge offering, for automating the build process, to work with the company’s source code analysis partners, including Fortify, Klocworks and Ounce Labs.
When the scanners run as part of the build, developers are less likely to resist their use, said IBM Rational vice president of marketing Scott Hebner. “They don’t want to break the build.” Forrester analyst Carey Schwaber agreed that doing static analysis at build time is a reasonable approach, but said, “I doubt a developer would consider a security flaw a broken build.”
Coverity open source strategist David Maxwell said conducting scans at build time can help keep developers from getting overwhelmed by false positive results that the scans are known to produce. Managers can vet the results before assigning fixes to individual developers. “A [potential vulnerability] might be low priority in one app, but not in another,” Maxwell said.
Coverity, which sells a source code analysis offering, also co-runs with Stanford University the Scan Project, which analyzes code in open source projects, reporting potential security flaws to developers who run those projects. Last month the Scan Project, funded by the U.S. Department of Homeland Security, added support for code written in Java, in addition to that written in C/C++.
Fortify's Chess emphasized that conducting the scan at build time is just one of three alternatives. Some development organizations prefer to run the tool on the programmer's desktop. Others choose to conduct scans only at major milestones, such as a design review, or when penetration tests are completed.
Chess also said that for large projects, asking developers to scan the entire codebase on their desktops is impractical because it takes too long.
A better approach is to break down the project in smaller parts, requiring each developer to scan only the code he has written.
|