Static Code Analysis to Detect Software Security Vulnerabilities - Does Experience Matter?

Baca, Dejan; Petersen, Kai; Carlsson, Bengt; Lundberg, Lars

doi:10.1109/ares.2009.163

Cited by 39 publications

(35 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…An alternative is to apply static analysis tools against the FOSS component. Such analysis requires a solid understanding of the FOSS source code [3], as well as expertise in the tools [11], as they can generate thousands of potentially false warnings for large projects. Further, the analysis may require days for processing even a single 'FOSS-release', 'main-application' pair [12].…”

Section: Is With University Of Luxembourg Luxembourg (He Performed Pmentioning

confidence: 99%

“…Figure 5 provides an intuition about the size of the changes made when fixing the CVEs from our sample. It combines the following three histograms: (1) the number of modified files; 11 (2) the number of modified Java methods; (3) the number of distinct added/deleted lines of code. In the majority of cases (51 out of 55), at most 5 files were modified, while in 29 cases it was only 1 file.…”

Section: Data Selectionmentioning

confidence: 99%

“…Additionally, in 40 cases the number of added/deleted lines of code was at most 50. This gives us an intuition that the majority of fixes were rather "local" and not spanning across multiple 11. Here we count only Java files, excluding unit tests.…”

Section: Data Selectionmentioning

confidence: 99%

“…As we only extract the relevant code within a set of methods (it takes less than a millisecond), while the slicer by Thome et al [26] extracts all potentially relevant sources and sinks. ( 11 ) this analysis for the conservative fix dependency screening are summarized in Table 4: it lists description of vulnerability types (taken from OWASP Top 10 13 ), as well as description of typical fixes for these vulnerabilities. The "completeness" column describes the dependencies of a fix that will be captured by the fix dependency sphere D * (code(r 0 ) , F ).…”

Section: Validationmentioning

confidence: 99%

See 3 more Smart Citations

A Screening Test for Disclosed Vulnerabilities in FOSS Components

Dashevskyi

Brucker

Massacci

2019

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

Abstract-Free and Open Source Software (FOSS) components are ubiquitous in both proprietary and open source applications. Each time a vulnerability is disclosed in a FOSS component, a software vendor using this component in an application must decide whether to update the FOSS component, patch the application itself, or just do nothing as the vulnerability is not applicable to the older version of the FOSS component used. This is particularly challenging for enterprise software vendors that consume thousands of FOSS components and offer more than a decade of support and security fixes for their applications. Moreover, customers expect vendors to react quickly on disclosed vulnerabilities-in case of widely discussed vulnerabilities such as Heartbleed, within hours. To address this challenge, we propose a screening test: a novel, automatic method based on thin slicing, for estimating quickly whether a given vulnerability is present in a consumed FOSS component by looking across its entire repository. We show that our screening test scales to large open source projects (e.g., Apache Tomcat, Spring Framework, Jenkins) that are routinely used by large software vendors, scanning thousands of commits and hundred thousands lines of code in a matter of minutes. Further, we provide insights on the empirical probability that, on the above mentioned projects, a potentially vulnerable component might not actually be vulnerable after all.

show abstract

Section: Is With University Of Luxembourg Luxembourg (He Performed Pmentioning

confidence: 99%

Section: Data Selectionmentioning

confidence: 99%

Section: Data Selectionmentioning

confidence: 99%

Section: Validationmentioning

confidence: 99%

See 2 more Smart Citations

A Screening Test for Disclosed Vulnerabilities in FOSS Components

Dashevskyi

Brucker

Massacci

2019

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

show abstract

“…Implementation vulnerabilities such as buffer overflows are added to the source while the developer writes it. For these types of vulnerabilities, static code analysis tools can be used for early detection [3,4]. Design vulnerabilities on the other hand can be introduced into the product before there is any source code to examine.…”

Section: Introductionmentioning

confidence: 99%

Prioritizing Countermeasures through the Countermeasure Method for Software Security (CM-Sec)

Baca

Petersen

2010

Product-Focused Software Process Improvement

Self Cite

View full text Add to dashboard Cite

Abstract. Software security is an important quality aspect of a software system. Therefore, it is important to integrate software security touch points throughout the development life-cycle. So far, the focus of touch points in the early phases has been on the identification of threats and attacks. In this paper we propose a novel method focusing on the end product by prioritizing countermeasures. The method provides an extension to attack trees and a process for identification and prioritization of countermeasures. The approach has been applied on an opensource application and showed that countermeasures could be identified. Furthermore, an analysis of the effectiveness and cost-efficiency of the countermeasures could be provided.

show abstract

Improving software security with static automated code analysis in an industry setting

et al. 2012

Self Cite

View full text Add to dashboard Cite

SUMMARY 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.

show abstract

Static Code Analysis to Detect Software Security Vulnerabilities - Does Experience Matter?

Cited by 39 publications

References 14 publications

A Screening Test for Disclosed Vulnerabilities in FOSS Components

A Screening Test for Disclosed Vulnerabilities in FOSS Components

Prioritizing Countermeasures through the Countermeasure Method for Software Security (CM-Sec)

Improving software security with static automated code analysis in an industry setting

Contact Info

Product

Resources

About