Improving software security with static automated code analysis in an industry setting. (20th February 2012)

• Record Type: Journal Article
• Authors: Baca, Dejan; Carlsson, Bengt; Petersen, Kai; Lundberg, Lars
• Is Part Of: Software, practice & experience. Volume 43:Number 3(2013)
• Page Start: 259
• Page End: 279
• Publication Date: 2012-02-20
• Subjects: Computer software -- Periodicals; Computer programming -- Periodicals; Computer programs -- Periodicals; 005.3
• DOI: 10.1002/spe.2109
• Languages: English
• ISSNs: 0038-0644

Abstract

<abstract abstract-type="main" id="spe2109-abs-0001"> <title>SUMMARY</title> <p id="spe2109-para-0001">Software security can be improved by identifying and correcting vulnerabilities. In order to reduce the cost of rework, vulnerabilities should be detected as early and efficiently as possible. Static automated code analysis is an approach for early detection. So far, only few empirical studies have been conducted in an industrial context to evaluate static automated code analysis. A case study was conducted to evaluate static code analysis in industry focusing on defect detection capability, deployment, and usage of static automated code analysis with a focus on software security. We identified that the tool was capable of detecting memory related vulnerabilities, but few vulnerabilities of other types. The deployment of the tool played an important role in its success as an early vulnerability detector, but also the developers perception of the tools merit. Classifying the warnings from the tool was harder for the developers than to correct them. The correction of false positives in some cases created new vulnerabilities in previously safe code. With regard to defect detection ability, we conclude that static code analysis is able to identify vulnerabilities in different categories. In terms of deployment, we conclude that the tool should be integrated with bug reporting systems, and developers need to share the responsibility for classifying and reporting warnings. With regard to tool usage by developers, we propose to use multiple persons (at least two) in classifying a warning. The same goes for making the decision of how to act based on the warning. Copyright © 2012 John Wiley & Sons, Ltd.</p> </abstract>