Vision: Identifying Affected Library Versions for Open Source Software Vulnerabilities

Susheng Wu,Ruisi Wang,Kaifeng Huang,Yiheng Cao,Wenyan Song,Zhuotong Zhou,Yiheng Huang,Bihuan Chen,Xin Peng
DOI: https://doi.org/10.1145/3691620.3695516
2024-01-01
Abstract:Vulnerability reports play a crucial role in mitigating open-source software risks. Typically, the vulnerability report contains affected versions of a software. However, despite the validation by security expert who discovers and vendors who review, the affected versions are not always accurate. Especially, the complexity of maintaining its accuracy increases significantly when dealing with multiple versions and their differences. Several advances have been made to identify affected versions. However, they still face limitations. First, some existing approaches identify affected versions based on repository-hosting platforms (i.e., GitHub), but these versions are not always consistent with those in package registries (i.e., Maven). Second, existing approaches fail to distinguish the importance of different vulnerable methods and patched statements in face of vulnerabilities with multiple methods and change hunks. To address these problems, this paper proposes a novel approach, Vision, to accurately identify affected library versions (ALVs) for vulnerabilities. Vision uses library versions from the package registry as inputs. To distinguish the importance of vulnerable methods and patched statements, Vision performs critical method selection and critical statement selection to prioritize important changes and their context. Furthermore, the vulnerability signature is represented by weighted inter-procedural program dependency graphs that incorporate critical methods and statements. Vision determines ALVs based on the similarities between these weighted graphs. Our evaluation demonstrates that Vision outperforms state-of-the-art approaches, achieving a precision of 0.91 and a recall of 0.94. Additionally, our evaluation shows the practical usefulness of Vision in correcting affected versions in existing vulnerability databases.
What problem does this paper attempt to address?