An Empirical Study of Usages, Updates and Risks of Third-Party Libraries in Java Projects 论文阅读笔记

An Empirical Study of Usages, Updates and Risks of Third-Party Libraries in Java Projects

• 研究背景及意义
• 相关工作
• • Usage Analysis
  • Update Analysis
  • Risk Analysis
• 研究方法和路线
• • 研究设计
  • 语料库选择
• 研究问题
• • RQ1 Library Use Analysis
  • • Usage Intensity
    • • Findings
    • Usage Outdateness
    • • Findings
  • RQ2 Library Update Analysis
  • • Update Intensity
    • • Findings
    • Update Delay
    • • Findings
  • RQ3 Library Risk Analysis
  • • Usage Risk
    • • Findings
    • Update Risk
    • • Findings
• 研究结果
• 有效性威胁
• 总结
• 个人思考
• • 可借鉴/优点：
  • TODO

研究背景及意义

第三方库是开发软件系统的核心构建块，给开发带来好处，提高生产力。但是，如果使用过时的第三方库，开发人员通常不太了解潜在的风险。
从开发者的角度来看，开发人员缺乏有效的机制来意识到使用和更新第三方库时的潜在风险（比如说API不兼容）。
从第三方库的角度来看，第三方库的开发者也缺乏有效的渠道来了解自己的第三方库在客户端项目中的使用和更新情况，此类信息无法反馈到库的开发周期以改进第三方库的设计。
因此，对第三方库的使用、更新和风险进行定量和整体研究可持续地改善生态系统。
那么为了可持续地改善这种情况，本文回答以下三个研究问题：第一，第三方库的使用强度和使用时效如何？第二，第三方库的更新强度和更新延迟如何？第三，使用和更新过时的第三方库有什么潜在风险？
通过以上三个问题的分析，本文定量和全面地描述 Java 生态系统中第三方库的使用、更新和风险，并为改善生态系统提供切实可行的见解。【提供了有关维护第三方库（例如，智能警报和自动更新过时库）的问题和潜在解决方案的实用见解。】
由此，本文对806个维护良好的Java开源项目和13565个第三方库进行库使用分析和库更新分析，对806个项目和13565个第三方库中的544个安全漏洞进行库风险分析。 本研究中的数据爬取和分析在台式机上花费了大约四个月的时间。 （可借鉴，数据集大）
可行的见解是什么？——>对于使用了有bug的库的项目，报告、建议了的更新库的版本

相关工作

那么本文与以往的工作有什么不同呢，也就是在现有的工作的基础上，多考虑了什么因素。

Usage Analysis

关于库的使用分析，现有研究包括：
M和K对库版本的使用趋势和流行度进行了研究;
Z等人分析了项目中使用的库版本和类的数量。
他们报告一个项目的库使用情况，但不报告整个项目的库使用情况。
L等人仅针对一个特定的库或项目在方法级别进行库使用分析，但没有衡量一系列库和项目的汇总结果。
总之，现有的 Java 生态系统库使用分析都只提供了有关库使用的部分方面。而本文是第一个在细粒度级别上全面分析项目和第三方库库使用情况的研究。

Update Analysis

关于库的更新分析，现有研究包括：
Bavota等人分析了开发人员更新依赖项的时间和原因，他们发现大量错误修复是依赖项更新的主要原因。
F等人探讨了库的发布周期与库版本更新之间的关系。
K等人分析了第三方库更新的实践，发现开发者很少更新库。
与这些研究不同的是，本文分别从项目和库的角度量化更新强度、更新延迟和更新风险。

Risk Analysis

关于库的风险分析，现有研究包括：
D等人分析了 Java 程序和依赖项的更新风险，发现 75% 的版本更新不兼容。
C等人提出了一个警报系统来报告具有安全漏洞的 Java 库依赖项。
而本文则是量化了这种不兼容性，通过调用图对库 API 的更改进行细粒度的分析。

缺陷库api数量和调用次数

研究方法和路线

研究设计

对于三个研究问题，设计的方法路线如下。
首先对于使用分析，分别从项目和库的角度分析对第三方库的依赖程度和使用时效，由此量化在项目开发中使用库的重要性以及不断发展的库的影响。
其次是更新分析，分别从项目和库的角度分析对第三方库更新程度和更新延迟。
最后是风险分析，对于项目，分析使用了多个有缺陷的库以及调用了有缺陷的库中的api数量；
对于库，分析存在多少安全漏洞，以及多少api不同于安全的库版本。由此量化使用过时的库的安全风险和API不兼容的风险。
然后就是对实验对象进行选取，也就是语料库选择。

语料库选择

本文研究者对从 GitHub 中选择的 Java 开源项目语料库进行了这项研究。本文专注于 Java，因为它被广泛使用，因此研究的发现可能对更广泛的受众有益。
具体来说，首先选择了github上 200 stars以上的 Java 项目，以确保项目质量，从而产生了最初的 2,216 个项目。
在这些项目中，我们筛选使用 Maven 或 Gradle 作为自动构建工具的项目，以便于提取项目中已声明的库依赖项，范围缩小到1,828 个项目中。
再次选择了在过去三个月内提交的活跃且维护良好的项目，因为来自维护良好的项目的受众可能更具代表性。最后，得到 806 个项目作为数据集，用大写的 P 表示。

研究问题

本文具体研究这三个问题。

RQ1 Library Use Analysis

第一个研究问题，研究第三方库的使用情况。
为了研究库的使用，本文开发了 library-extractor 以在一次提交中从每个项目的配置文件中提取库依赖项。
库依赖项 d 表示为 这个4 元组
运行lib-extracter:

对 P 中每个项目的最新提交运行 lib-extractor，并获得 164,470 个库依赖项，表示为 Dus，24,205
个库版本，表示为 Vus = {d.v | d ∈Dus}，以及 13,565 个库，表示为 Lus = {v.l | v∈Vus}。

Usage Intensity

首先是对第三方库使用强度的分析。
从项目和库的角度分别定义第三方库使用强度：
一是项目 p 的方法调用第三方库 API 的百分比，二是库 l 的 API 被其他项目调用的百分比。
要计算这两个参数 usip 和 usil，我们需要提取第三方库的 API、项目中的方法和项目方法中对第三方库的 API 调用。这里借助了Soot和javaparser两个代码分析工具。

1. 通过爬取jar包得到类文件
2. 使用Soot提取库中的API
   这里我们保守地将公共类中的公共方法和字段视为库 API。
3. 使用 JavaParser 解析项目使用了库中的哪些api，项目方法，表示为 M，以及项目方法中的 API 调用， 表示为C。
   m ∈ M p表示项目，method表示项目中的方法；
   c ∈ C a表示库的api，m表示项目中调用a的方法
   通过上述几个参数（P Vus Lus A M C），可以计算usip & usil
   

解释一下公式：如图所示，项目使用密集度 usip = 调用第三方库的方法数目/项目总的方法数目
我的理解是：对于同一第三方库的不同版本 usil = 被调用的api数目/该第三方库所有api数目 取最大值

Findings

最后得到统计计算结果，结果如下：

● 图1.a: 纵坐标表示项目数量，横坐标表示调用第三方库api的百分比。
● 图1.b:横坐标表示库的数量，横坐标表示跨库调用的百分比。
可以看到，从项目角度来看，小部分项目不调用库 API，大部分项目对库依赖性在10%~40%之间。
从第三方库的角度，60.0%的库最多只有 2% 的 API 被其他项目调用；只有3.9%个库有超过 40% 的 API 被其他项目调用。
可以看出：项目通常对库 API 具有适度的依赖性。这种具体的使用依赖性也反映了库的维护所需的努力。
第二是 大多数库中只有非常小的一部分库API被使用。说明库的开发人员可以去除一些未使用的库功能。

Usage Outdateness

第二点就是关于库使用是否过时的评估。
本文定义一个库依赖 d 的使用过时度，表示为 use-outdate，作为在库爬取时具有更高版本号的库发布的数量。

并从项目和库的角度分别定义第三方库使用过时度：一是项目 p 库依赖项的平均使用过时度uso_l–库 l 的库依赖项的平均使用过时度。

Findings

得到统计结果如图所示：

研究结果发现只有 3.5%项目使用最新的库版本。10.3%项目使用的库平均最多与最新版本相差两个版本。 剩下大部分项目采用的库与最新版本相差较大。
对于第三方库， 在所有使用它们的项目中，45.2%个调用的库已经是最新的，1,419 (19.6%) 个调用的库平均最多与最新版本相差两个版本，14.2% 库是最新的调用的平均分别与最新版本相差超过 10个版本。
可以得到：
几乎每个项目都会采用过时的库。项目所使用的第三方库版本通常与最新版本的距离很大。因此，需要有机制让项目开发人员意识到过时库的风险（例如，安全漏洞）或新版本的好处（例如，新功能）。
于是就有了之后两个研究。

RQ2 Library Update Analysis

关于研究问题2，为了研究库的升级，本文开发了 update-extractor 来从项目的提交历史中提取库版本更新。

它扫描项目 p 的提交以识别每个更改 p 的配置文件的提交 com。然后在 com 和 com 之前的提交上使用lib-extractor（见 Sec.IV），分别提取 com之前和之后的库依赖。最后，利用这两组库依赖，通过搜索版本号发生变化的库依赖来识别库版本更新。
每个库版本更新 u 表示为一个 6 元组，其中 p, f, com 和 l 分别表示 u所在的项目、配置文件、提交和库，以及ver1和ver2分别表示更新前后的版本号。

Update Intensity

从项目和库的角度分别定义第三方库更新强度：upip: 项目 p 当前声明的库依赖项其版本号在 p 的提交中更新所占的百分比；upil，调用库l的项目中，对库l进行更新的项目所占百分比

Findings

得到统计结果如图所示：

项目角度来看，14.1%的项目没有更新任何当前声明的库依赖项。大部分项目更新了20%-50%的库依赖项，少部分项目更新了超过80% 的库依赖项。
第三方库的角度来看，4**,414 (32.5%) 个库在所有依赖它们的项目中从未更新过。** 65.4%的库在超过一半的依赖它们的项目中没有被更新。
可以看出，大部分项目的开发人员确实会更新库。尽管如此，仍有一半的项目让其超过一半的第三方库从未更新；三分之一的库在使用它们的项目中没有被更新过。考虑到所选项目维护良好，但是更新实践相对差。由此可见，应该提高对更新库的重要性的认识。

Update Delay

那么开发者对库更新的敏感程度如何呢？本文定义一个库版本更新 u 的更新延迟，记为 update delay-u，作为 u 的提交日期和 u 之后的库版本发布日期之间的延迟。
对于每一个版本更新u，爬取库的发布数据。
并且从项目和第三方库的角度分别去分析更新延迟。

Findings

得到统计结果：

从项目的角度来看，23.1%的项目最多延迟 30 天更新其库依赖项。大部分项目的更新延迟s超过 60天。
从库的角度来看，72.6%个库的更新延迟最多为 30 天。剩下库的更新延迟超过 60天。
可以看出，开发人员对新库的发布反应迟缓。库发布新版本，开发人员延迟更新，可能会增加使用过时库的风险（例如，安全漏洞），甚至会增加更新到新版本的难度，因为在此时间窗口内其他项目可能将使用更多的过时库 API。

RQ3 Library Risk Analysis

那么使用过时的库风险情况如何呢？为了研究库的风险，本文开发了 bug-extractor来收集库中的安全漏洞，首先从 Veracode 的漏洞数据库中爬取每个安全漏洞的元数据。

【Veracode静态源代码分析服务平台是全球商业运营最好的平台，全球数千家 软件科技公司都在使用其服务发现软件安全漏洞、质量缺陷】
中搜索，然后爬取每个安全漏洞的元数据（例如，受影响的库版本和安全补丁）。

Usage Risk

我们将一个项目的使用风险定义为两个指标：一是一个项目使用的有缺陷的库版本的数量；二是一个项目使用的有缺陷的库版本中的安全漏洞的数量。
将库版本的使用风险定义为库版本中的安全漏洞数量。

Findings

计算得到统计结果：

可以得到，56.0%的项目采用有缺陷的库版本；其中大部分缺陷库版本在1-5个之间，少部分使用超过5个有缺陷的库版本。
在这么多个库版本中，只有31.2%个库版本没有安全漏洞。 34.2%的库版本有 1 个安全漏洞。剩下的超过2个安全漏洞。
可以看出，超过一半的项目使用包含安全漏洞的库版本。三分之二的库版本包含安全漏洞。安全漏洞的相对普遍存在表明，如果项目开发人员没有意识到使用库中的安全漏洞或延迟库更新，项目将面临潜在风险。

Update Risk

但是如果开发者贸然更新库也会存在更新风险。
本文将项目的更新风险定义为两个指标：一是项目使用的有缺陷的库版本调用 API 的数量（调用了有bug库的多少api），二是对项目使用的错误库版本的 API 调用次数。
将有缺陷的版本的更新风险定义为两个指标：一是安全的库版本中删除的缺陷库版本中的 API 数量；二是安全的库版本中修改的缺陷库版本中的 API 数量

Findings

得到统计结果

在451个采用有bug的库版本的项目中，三分之一的项目在使用的bug库版本中没有调用API，大部分调用了1-20个API，少部分项目调用超过40个API。
38.3%有缺陷的库版本在安全的库版本中修改了不到 40 个 API，而 24.4%个有缺陷的库版本在安全库版本中修改了超过 100 个 API。2,065 (17.2%) 个有缺陷的库版本在安全库版本中删除了不到 40 个 API。4,236 (35.3%) 个有缺陷的库版本在安全版本中删除了 300 多个 API。
由此可以得到结论： 使用有缺陷的库的API存在中度风险。需要工具结合项目中使用的库 API 和在安全版本中更改的库 API 来提供对风险的严格估计，以便开发人员更有把握地更新有缺陷的库。

研究结果

？项目演示&结果
并没有找到如何使用这个系统？看不到直观的结果。无法测试自己的数据。开源的只有研究结果和数据集和工具代码。

基于上述量化指标和统计结果，本文设计了一个针对有缺陷库的安全错误驱动警报系统。包括两个主要模块：风险分析和（更新库版本建议的）工作量分析。
然后本研究针对 451 个使用了有缺陷的库的项目运行了这个警报系统，看有问题的库是否影响系统。我们发现 413 个项目不受 bug 库的影响并且可以是安全的。剩下34个受bug影响的项目。
表1列出了10个受有bug的库影响的项目，其中 BL 是影响项目的错误库数量，NB、NA 和 NC 是风险分析中报告的指标（其中安全错误总数、调用库 API 和对库 API 的调用列在括号中），SL 是建议库版本的数量，其他列列出了一个建议库版本的工作量分析指标。
但是这个警报系统并不是开源&可视化的，在网站上只能看到对节选项目的研究结果。

不能测试自己的项目数据，没有得到更直观的数据。
开源的只有数据集。以及基础代码（爬取的代码）

有效性威胁

最后，本研究讨论了可能的有效性威胁，包括

1. 间接依赖。本研究重点在于直接依赖的库，即在项目配置文件中声明的库。如果考虑间接库依赖，对库的依赖会更重，安全漏洞方面的潜在风险会更高。如果继续深挖、考虑间接依赖，会十分复杂。
2. （数据的）主体代表性。本研究使用维护良好的项目，而筛选掉了不活跃的项目。需要对那些维护不好的项目进行独立研究，以比较结果。此外，研究者无法爬取一些库的 jar 文件和发布日期，因此它们在一些分析中被排除。但是由于数据集规模庞大，研究的数据仍然具有代表性和意义。

总结

本文主要做了以下工作：
● 一是进行了大规模的实证分析，定量、全面地分析了第三方库在 Java 开源项目中的使用、更新和风险。
● 二是向开发人员和研究人员提供了实际意义，发布了数据集，并提出了一个原型系统LIBRARY-SECURIFY，用于协助开发者在更新过时的第三方库时，通过量化风险做出更有把握的决定。证明了研究发现的有用性。

个人思考

可借鉴/优点：

1. 工作量大，数据集大
   数据集爬取耗费四个月，并且进行了筛选，数据集庞大，具有可信性和代表性。
2. 这篇文章提到的许多的相关工作可以去细看一下，比如说JavaParser
3. 量化评估指标，使研究更具有可行性代表性
   思想上有哪些值得学习的地方？
   既考虑到项目开发者，反馈所使用库的缺陷
   又考虑到第三方库的开发者，
   从两个方面共同促进软件生态。

TODO

项目数据集开源，但是系统并未开源（？

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！