Skip to main content
zenodoopen

An Exploration on How Developers Respond to Security Vulnerabilities: The Case of Log4JShell

<p>Although using third-party libraries has become prevalent in contemporary software development, developers often struggle to update their dependencies. Prior works acknowledge that due to the migration effort, priority and other issues cause lags in the migration process. The common assumption is that developers should drop all other activities and prioritize fixing the vulnerability.<br> Our objective is to understand developer behavior when facing high-risk vulnerabilities in their code. We explore the prolific case of the Log4Shell, a vulnerability that has the highest severity rating ever, which received widespread media attention. Using a mixed-method approach, we analyze 219 GitHub Pull Requests (PR) and 354 issues belonging to 53 &nbsp;Maven projects affected by the Log4j vulnerability. Our study indicates that developers tend to have a quick response taking from 5 to 6 days. However, instead of focusing on fixing the vulnerability, surprisingly developer activities tend to increase for all pending issues and PRs.&nbsp; Developer discussions involved either giving information (29.3%) and seeking information (20.6%), which is missing in existing support tools. Leveraging this possibly-one of a kind event opens up a new line of research, advocating us to rethink best practices and what developers need in order to efficiently fix vulnerabilities.</p>

ShareScore

32/100

Overall dataset sharing score

Score breakdown

These five areas show where the dataset supports — or may limit — practical reuse.

Stewardship
4
Harmonization
4
Access
16
Reuse readiness
8
Engagement
0