The impact of tangled code changes on defect prediction models

A Screening Test for Disclosed Vulnerabilities in FOSS Components

“…There is a potential bias in bug-fix commits, such that along with fixing relevant parts of the functionality, developers may introduce irrelevant changes (e.g., refactor some unrelated code). Kawrykow and Robillard [47], and Herzig et al [21] explored to what extent bug-fix commits may include changes irrelevant to the original purpose of the fix: while they show that there may be significant amount of irrelevant changes for general bugs, Nguyen et al [20] observed that for the majority of security fixes this was not the case -this is also supported by our findings of very "local" changes ( Figure 5). The subset of vulnerabilities that we checked manually did not contain such refactorings.…”

“…We selected the FOSS projects based on the needs of our industrial partner, i.e., we selected the most often used components across a wide spectrum of enterprise applications and frameworks developed by our partner. First, we performed a manual validation to determine the potential error rate of different screening criteria, and, second, we did a large scale empirical analysis of the underlying assumptions (e.g., security fixes in our projects are mostly local as in [20], in contrast to what is found on normal bugs [21]), as well as the trade-offs between the likelihood that an older version is affected by a newly disclosed vulnerability and the maintenance effort required for upgrading, showing that the approach scales to thousands of revisions and MLoCs.…”

“…However, we decided to remove Jenkins from the manually checked sample as we wanted the ground truth to be accurate. 13 [21], [47] but it was not present in our projects, as the (vulnerable) security checks and the related fix are normally quite distinct from the code of the method that implements other functionalities. The final sample for the manual assessment consisted of 126 data points across the total of 126193 revisions that correspond to the histories of 21 CVEs (randomly selected across the projects shown in Table 2): we went backwards iteratively, and for many revisions the vulnerability evidence did not change.…”

Guest editorial: Special section on mining software repositories

“…The purpose of such analysis could be, on the one hand, of observing the evolution of software projects, and on the other hand of building different forms of recommenders to support software engineering in their activities.This special section features three mining software repository papers dealing with one very important aspect of software evolution, i.e., software defects, and specifically their prediction, localization, and triaging.In the paper "The Impact of Tangled Code Changes on Bug Defect Prediction Models" (Herzig et al 2015) study the impact of tangled changes on defect prediction models. Tangled changes occur when developers commit together unrelated code changes within a single transaction.…”

“…In the paper "The Impact of Tangled Code Changes on Bug Defect Prediction Models" (Herzig et al 2015) study the impact of tangled changes on defect prediction models. Tangled changes occur when developers commit together unrelated code changes within a single transaction.…”