原文标题：An empirical study of usages, updates and risks of third-party libraries in java projects

原文作者：Ying Wang. Bihuan Chen, Kaifeng Huang, Bowen Shi, Congying Xu, Xin Peng, et al

原文链接：https://arxiv.org/pdf/2002.11028.pdf

发表会议：ICSME"20

笔记作者：NING@SecQuan

笔记小编：ourren@SecQuan

1 研究介绍

第三方库（Library）的使用，帮助我们不在重新造轮子，但与此同时也为项目（Project）带来了异步风险。第三方库延迟更新、很少更新、包含漏洞代码等，都会为项目增加可能的攻击面，同时第三方库的修复、维护也需要项目开发者及时同步，从而避免不必要的风险。因此本文是从第三方库的使用、更新、风险三方面出发，进行一个定量、全面的研究，从而为 JAVA 生态做出一些贡献。本文主要聚焦于以下三个问题，并同时提出了一个原型系统来对问题研究结果进行验证。

  • RQ1：使用分析，Library 的使用强度与时效。

  • RQ2：更新分析，Library 的更新强度与延迟。

  • RQ3：风险分析，使用和更新过时 Library 的潜在风险。

文章为了更好的展现研究的真实性，通过数学方式定义了多个指标，并且通过其对真实 JAVA 生态情况进行了量化分析。本文主要选用的是 200 stars 以上的 Java 项目（最终 1828 个），

2 使用分析

文章从使用强度、使用过时两方面来进行研究。

图 1 跨项目和库的使用强度分布

使用强度：

经研究发现，74(9.2%) 的项目没有调用库的 API，265(32.9%) 的项目调用库 API 比例不超过 10%，266(33.0%) 和 64(7.9%) 的项目调用库 API 分别超过 20% 和 40%。由此可见，项目通常对库的 API 是存在依赖性的，但同时库的开发人员也可以根据此信息进行 API 的调整。

图 2 跨项目和库的使用过时分布

使用过时：

研究表明，82(10.3%) 项目使用的库平均最多与最新版本相差两个版本。306(38.0%)、118(14.6%) 和 19(2.4%) 个项目采用的库分别与最新版本平均相差超过 10、20 和 50 个版本。可以看到几乎所有的项目使用的都是过时的版本，因此这方面必然会存在功能和安全性的差距。

3 更新分析

文章定义了更新强度、更新延迟两个概念来进行研究。

图 3 跨项目和库的更新强度分布

更新强度：

89(11.0%) 和 329(40.8%) 个项目分别更新了最多 20% 和 50% 的当前声明的库依赖项。354(43.9%) 和 101(12.5%) 个项目分别更新了超过 50% 和 80% 的当前声明的库依赖项。另一方面，4,414(32.5%) 个库在所有依赖它们的项目中从未更新过。可以看到项目的更新强度不高，尽管项目维护良好，但更新相当差。

图 4 跨项目和库的更新延迟分布

更新延迟：

186(23.1%) 项目最多延迟 30 天更新其库依赖项。407(50.5%)、256(31.8%) 和 174(21.6%) 个项目的更新延迟分别超过 60、120 和 180 天。13.3% 个项目未包含在图 5a 中因为其无法计算更新延迟（即，90 个项目从未更新任何库依赖项；17 个项目更新了库依赖项，但我们未能抓取发布日期）。项目开发人员对新库的发布反应迟缓。如此宽的时间窗口可能会增加使用过时库的风险（例如，安全漏洞），甚至会增加更新到新版本的难度，因为在此时间窗口内将使用更多的库 API。

4 风险分析

文章定义了使用风险、更新风险两个概念来进行研究。

图 5 跨项目和库版本的使用风险分布

451(56.0%) 个项目采用有缺陷的库版本。328(40.7%) 个项目采用 1 到 5 个有缺陷的库版本，128(15.3%)个项目甚至使用超过 5 个有缺陷的库版本。在 25.7% 项目中，他们使用的有缺陷的库版本有 1 到 5 个安全漏洞。在 188(23.3%) 项目中，他们使用的 bug 库版本甚至有超过 10 个安全漏洞。超过一半的项目使用包含安全漏洞的库版本。三分之二的库版本包含安全漏洞。安全漏洞的相对普遍存在表明，如果项目开发人员没有意识到使用库中的安全漏洞或延迟库更新，项目将面临潜在风险。

在采用有 bug 的库版本的 451 个项目中，有 151(33.5%) 项目没有在使用过的有 bug 的库版本中调用 API，181(40.1%) 项目最多调用 20 个 API，82(18.2%) 项目调用超过 40 个 API。此外 4,236(35.3%) 个有缺陷的库版本在安全版本中删除了 300 多个 API。API 的使用需要及时关注，可能存在安全风险。开发人员应当及时关注库 API 的修改情况。

5 个人思考

  • 当下 Java 生态或者说其他软件包供应链生态中，往往可能由于代码量大，研究人员代码更新等情况而存在大量的未使用第三方库，这对于软件工程来说是一个值得研究的问题。

  • Java 代码安全性和漏洞传播也是值得研究的点（尤其 Java 的反射机制可能会有一些研究价值？）。

  • Java 包臃肿问题近些年确实有一些研究，这方面同样还有一些提升的空间。

安全学术圈招募队友-ing

有兴趣加入学术圈的请联系secdr#qq.com

声明：本文来自安全学术圈，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。