A Screening Test for Disclosed Vulnerabilities in FOSS Components

Abstract

Abstract-Free and Open Source Software (FOSS) components are ubiquitous in both proprietary and open source applications. Each time a vulnerability is disclosed in a FOSS component, a software vendor using this component in an application must decide whether to update the FOSS component, patch the application itself, or just do nothing as the vulnerability is not applicable to the older version of the FOSS component used. This is particularly challenging for enterprise software vendors that consume thousands of FOSS components and offer more than a decade of support and security fixes for their applications. Moreover, customers expect vendors to react quickly on disclosed vulnerabilities-in case of widely discussed vulnerabilities such as Heartbleed, within hours. To address this challenge, we propose a screening test: a novel, automatic method based on thin slicing, for estimating quickly whether a given vulnerability is present in a consumed FOSS component by looking across its entire repository. We show that our screening test scales to large open source projects (e.g., Apache Tomcat, Spring Framework, Jenkins) that are routinely used by large software vendors, scanning thousands of commits and hundred thousands lines of code in a matter of minutes. Further, we provide insights on the empirical probability that, on the above mentioned projects, a potentially vulnerable component might not actually be vulnerable after all.

Vuln4Real: A Methodology for Counting Actually Vulnerable Dependencies

“…• If a patch to fix the vulnerability in the dependency exists use the code-base approach by Plate et al [18] and [29] to compare the nodes of the dependency tree of the version of interest to check whether one of them is affected • If no such fix exists report the vulnerability according to database approach (i.e., listed version in the vulnerability dataset).…”

“…To avoid the false positive and false negative inflation introduced by name-based vulnerability matching ( [13], [14], [15]), we leverage on precise code-based approaches to vulnerability detection such as Ponta et al [6] and Dashevskyi et al [29]. Starting from known vulnerabilities disclosed in the NVD, advisories, bug tracking systems, etc., we manually identified and analyzed the commit fixing the vulnerability.…”

“…We have also extracted the number of usages of the libraries in our sample as reported in mvnrepository.com. Figure 4 shows that the libraries in our sample are popular 29 within FOSS projects: 121 libraries are used by more than 1000 other libraries (and even more library versions), while median library has 291 dependents.…”

“…• applies path simplifications and produces the results in the form of a human-readable report. 29. We have manually checked 27 libraries that have less than 10 usages and we found that they might be industry-specific libraries: e.g., they may have groupIds like com.sap.*.…”

Secure Software Development in the Era of Fluid Multi-party Open Software and Services

“…. Unfortunately, MOSS prosumers cannot expect to systematically receive information about security flaws in the 3rd party components of their projects [E2.3]: the practices for reporting vulnerabilities vary across projects and ecosystems, and it is well-known that only a minor part is represented in de-facto vulnerability databases such as the NVD [38], which also suffer from poor accuracy [39], [40]. This makes it difficult for applications that depend on those components to understand the impact of the vulnerability and to correctly determine and compare mitigation strategies (e.g., whether upgrading to a more recent, non-vulnerable version of the component is urgent, or if an application-level change could effectively mitigate the vulnerability at hand and make a potentially expensive version update unnecessary [41]).…”