Background: Regressions occur whenever a piece of software that previously worked correctly no longer works as intended. They often happen as a result of changes to the source code (e.g., a bug fix). Security regressions can have severe effects on both users and developers of software systems. However, knowledge on security regressions is still limited: e.g., little is known about how, why, and when these regressions happen. Studying these characteristics is an important step in pushing secure software engineering forward.

Aims: To increase the understanding of security regressions.

Method: We perform an exploratory mixed-method study. First, we inspect Mozilla’s bug reports whose fixing introduced security issues. We investigate how developers interact in these bug reports, how they perform the changes, and under what conditions they introduce regression vulnerabilities. In total, we analyze 78 regression vulnerabilities and 72 bug reports where a bug fix introduced a regression vulnerability. Following, we conduct semi-structured interviews with five Mozilla developers involved in the vulnerability-inducing bug fixes.

Results: Software security is not discussed during bug fixes. When fixing bugs, developers’ main concerns are the bug’s complexity and the community pressure to fix it. Moreover, developers report not to worry about regression vulnerabilities since they assume tools would later detect them. In fact, dynamic analysis tools played an essential role in finding around 30% of regression vulnerabilities at Mozilla.

Conclusions: These results provide evidence that, although tool support helps identify regression vulnerabilities, these tools may not be enough to ensure security during bug fixes. Furthermore, our results call for further work on the security tooling support and how to integrate them during bug fixes.