Abstract:Vulnerabilities publicly disclosed in the National Vulnerability Database (NVD) are assigned with CVE (Common Vulnerabilities and Exposures) IDs and associated with specific software versions. Many organizations, including IT companies and government, heavily rely on the disclosed vulnerabilities in NVD to mitigate their security risks. Once a software is claimed as vulnerable by NVD, these organizations would examine the presence of the vulnerable versions of the software and assess the impact on themselves. However, the version information about vulnerable software in NVD is not always reliable. Nguyen et al. find that the version information of many CVE vulnerabilities is spurious and propose an approach based on the original SZZ algorithm (i.e., an approach to identify bug-introducing commits) to assess the software versions affected by CVE vulnerabilities. However, SZZ algorithms are designed for common bugs, while vulnerabilities and bugs are different. Many bugs are introduced by a recent bug-fixing commit, but vulnerabilities are usually introduced in their initial versions. Thus, the current SZZ algorithms often fail to identify the inducing commits for vulnerabilities. Therefore, in this study, we propose an approach based on an improved SZZ algorithm to refine software versions affected by CVE vulnerabilities. Our proposed SZZ algorithm leverages the line mapping algorithms to identify the earliest commit that modified the vulnerable lines, and then considers these commits to be the vulnerability-inducing commits, as opposed to the previous SZZ algorithms that assume the commits that last modified the buggy lines as the inducing commits. To evaluate our proposed approach, we manually annotate the true inducing commits and verify the vulnerable versions for 172 CVE vulnerabilities with fixing commits from two publicly available datasets with five C/C++ and 41 Java projects, respectively. We find that 99 out of 172 vulnerabilities whose version information is spurious. The experiment results show that our proposed approach can identify more vulnerabilities with the true inducing commits and correct vulnerable versions than the previous SZZ algorithms. Our approach outperforms the previous SZZ algorithms in terms of F1-score for identifying vulnerability-inducing commits on both C/C++ and Java projects (0.736 and 0.630, respectively). For refining vulnerable versions, our approach also achieves the best performance on the two datasets in terms of F1-score (0.928 and 0.952).

Research on the distribution of CVSS environmental scores

Categorizing and Predicting Invalid Vulnerabilities on Common Vulnerabilities and Exposures

Shedding Light on CVSS Scoring Inconsistencies: A User-Centric Study on Evaluating Widespread Security Vulnerabilities

Unveil the Mystery of Critical Software Vulnerabilities

V-SZZ: Automatic Identification of Version Ranges Affected by CVE Vulnerabilities

Patchmatch: A Tool for Locating Patches of Open Source Project Vulnerabilities

Towards More Practical Automation of Vulnerability Assessment

An Improved CVSS-based Vulnerability Scoring Mechanism

A Look at the Time Delays in CVSS Vulnerability Scoring

Risk Based Vulnerability Assessment for Hvdc Transmission System

A Historical and Statistical Studyof the Software Vulnerability Landscape

Gotta Catch 'em All: Aggregating CVSS Scores

Computer Network System Security Assessment Method.

My Software has a Vulnerability, should I worry?

Quantitative Security Risk Evaluation using CVSS Metrics by Estimation of Frequency and Maturity of Exploit

The Study of Quantitative Assessment of Regional Eco-environmental Vulnerability Based on Multi-source Remote Sensing

Assessment method of automatic optimizing CVSS v20 vulnerability indi-cator s

SecScore: Enhancing the CVSS Threat Metric Group with Empirical Evidences

Identifying Relevant Information Cues for Vulnerability Assessment Using CVSS

RISK-BASED VULNERABILITY ASSESSMENT IN COMPLEX POWER SYSTEMS

Support for the Vulnerability Management Process Using Conversion CVSS Base Score 2.0 to 3.x