Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Discovery of Timeline and Crowd Reaction of Software Vulnerability Disclosures

Yi Wen Heng, Zeyang Ma, Haoxiang Zhang, Zhenhao Li, Tse-Hsun, Chen

TL;DR

This manual study focuses on the real-world practices (crowd reaction) adopted by software vendors and developer communities when a vulnerability is disclosed and identified Oracle as the most vibrant community diligent in releasing fixes.

Abstract

Reusing third-party libraries increases productivity and saves time and costs for developers. However, the downside is the presence of vulnerabilities in those libraries, which can lead to catastrophic outcomes. For instance, Apache Log4J was found to be vulnerable to remote code execution attacks. A total of more than 35,000 packages were forced to update their Log4J libraries with the latest version. Although several studies have been conducted to predict software vulnerabilities, the prediction does not cover the vulnerabilities found in third-party libraries. Even if the developers are aware of the forthcoming issue, replicating a function similar to the libraries would be time-consuming and labour-intensive. Nevertheless, it is practically reasonable for software developers to update their third-party libraries (and dependencies) whenever the software vendors have released a vulnerable-free version. In this work, our manual study focuses on the real-world practices (crowd reaction) adopted by software vendors and developer communities when a vulnerability is disclosed. We manually investigated 312 CVEs and identified that the primary trend of vulnerability handling is to provide a fix before publishing an announcement. Otherwise, developers wait an average of 10 days for a fix if it is unavailable upon the announcement. Additionally, the crowd reaction is oblivious to the vulnerability severity. In particular, we identified Oracle as the most vibrant community diligent in releasing fixes. Their software developers also actively participate in the associated vulnerability announcements.

Discovery of Timeline and Crowd Reaction of Software Vulnerability Disclosures

TL;DR

This manual study focuses on the real-world practices (crowd reaction) adopted by software vendors and developer communities when a vulnerability is disclosed and identified Oracle as the most vibrant community diligent in releasing fixes.

Abstract

Reusing third-party libraries increases productivity and saves time and costs for developers. However, the downside is the presence of vulnerabilities in those libraries, which can lead to catastrophic outcomes. For instance, Apache Log4J was found to be vulnerable to remote code execution attacks. A total of more than 35,000 packages were forced to update their Log4J libraries with the latest version. Although several studies have been conducted to predict software vulnerabilities, the prediction does not cover the vulnerabilities found in third-party libraries. Even if the developers are aware of the forthcoming issue, replicating a function similar to the libraries would be time-consuming and labour-intensive. Nevertheless, it is practically reasonable for software developers to update their third-party libraries (and dependencies) whenever the software vendors have released a vulnerable-free version. In this work, our manual study focuses on the real-world practices (crowd reaction) adopted by software vendors and developer communities when a vulnerability is disclosed. We manually investigated 312 CVEs and identified that the primary trend of vulnerability handling is to provide a fix before publishing an announcement. Otherwise, developers wait an average of 10 days for a fix if it is unavailable upon the announcement. Additionally, the crowd reaction is oblivious to the vulnerability severity. In particular, we identified Oracle as the most vibrant community diligent in releasing fixes. Their software developers also actively participate in the associated vulnerability announcements.

Paper Structure

This paper contains 19 sections, 5 figures, 8 tables.

Table of Contents

  1. Introduction
  2. Background and Motivating Examples
  3. Reporting and Managing Common Vulnerabilities and Exposures
  4. A Motivation Example
  5. Methodology
  6. Data Collection
  7. Manual Study Process
  8. Methodological Challenges and Mitigation Strategies
  9. An Example of the Vulnerability Lifecycle
  10. STUDY RESULTS
  11. RQ1: What are the lifecycles of CVE reports?
  12. RQ2: What are the time gaps between different stages in the lifecycle of vulnerability management?
  13. RQ3: What are the characteristics of vulnerability response handling?
  14. Discussions
  15. Implications for Software Library Developers
  16. ...and 4 more sections

Figures (5)

  • Figure 1: The lifecycle of how a CVE is discovered and recorded by developers, CNAs, MITRE, and NVD.
  • Figure 2: CVE-2021-44228 Record Changes: Initially reserved on December 4, 2021, with no details, the entry was updated on December 10, 2021, to include the root cause and potential mitigations.
  • Figure 3: GitHub Security Advisory for CVE-2020-26222 with Inspect Element tool to unveil the specific timestamp of a change.
  • Figure 4: Number of days taken between events. Green stars indicate the mean values.
  • Figure 5: Vendor Insights: A Comprehensive Analysis of Vendor Distribution, Severity Scores, and Update Timeliness. Green stars indicate the mean values.