The Impact of a Major Security Event on an Open Source Project: The Case of OpenSSL

TL;DR

The paper analyzes how the Heartbleed security incident prompted OpenSSL to significantly improve its code quality, security practices, and project activity, serving as a model for open source project resilience after security crises.

Contribution

This study provides a detailed case analysis of OpenSSL's post-Heartbleed evolution, highlighting improvements in code quality, security practices, and project activity, with a mixed methods approach.

Findings

OpenSSL's commits per month tripled after Heartbleed

91 vulnerabilities were identified and fixed post-incident

OpenSSL achieved a CII best practices badge

Abstract

Context: The Heartbleed vulnerability brought OpenSSL to international attention in 2014. The almost moribund project was a key security component in public web servers and over a billion mobile devices. This vulnerability led to new investments in OpenSSL. Objective: The goal of this study is to determine how the Heartbleed vulnerability changed the software evolution of OpenSSL. We study changes in vulnerabilities, code quality, project activity, and software engineering practices. Method: We use a mixed methods approach, collecting multiple types of quantitative data and qualitative data from web sites and an interview with a developer who worked on post-Heartbleed changes. We use regression discontinuity analysis to determine changes in levels and slopes of code and project activity metrics resulting from Heartbleed. Results: The OpenSSL project made tremendous improvements to code quality and security after Heartbleed. By the end of 2016, the number of commits per month had tripled, 91 vulnerabilities were found and fixed, code complexity decreased significantly, and OpenSSL obtained a CII best practices badge, certifying its use of good open source development practices. Conclusions: The OpenSSL project provides a model of how an open source project can adapt and improve after a security event. The evolution of OpenSSL shows that the number of known vulnerabilities is not a useful indicator of project security. A small number of vulnerabilities may simply indicate that a project does not expend much effort to finding vulnerabilities. This study suggests that project activity and CII badge best practices may be better indicators of code quality and security than vulnerability counts.