背景
第三方库允许开发人员重用常用功能，提高开发人员的工作效率。但是由于第三方库和客户端项目之间的异步演化，会出现一些问题。
- 客户端项目中可能会使用过时的第三方库，而开发人员却没有意识到潜在的风险（例如，安全漏洞）。
- 旧的第三方库版本包含错误，可能会导致客户端项目崩溃或增加攻击面。
- 新的第三方库版本重构代码、修复错误并添加功能，这可能会破坏库 API。
为了为这些问题提供具体和全面的证据，需要对开源项目中第三方库的使用、更新和风险进行定量和整体研究。
数据集
选自 GitHub 的 Java 开源项目语料库，选择 200 star 以上非 fork 且使用 Maven 或 Gradle 作为自动构建工具的项目，在过去三个月内提交的活跃且维护良好的项目。
最终，作者得到了 806 个开源项目进行库使用分析和库更新分析。
实证研究方法
第三方库使用分析
作者开发了 lib-extractor 在每个项目的配置文件（pom.xml、build.gradle) 中提取依赖项
- 例如：对于 Maven 项目， lib-extractor 通过解析三个字段来提取库依赖：groupId、artifactId 和 version；
作者对上述数据集（806个Java项目）中每个项目的最新提交运行 lib-extractor，得到 164,470 个库依赖项，记为 
，24,205 个库版本，记为 
，以及 13,565 个库，表示为 
。
使用强度
作者从项目和库的角度在细粒度级别定义使用强度：
，项目 p 调用库 API 的方法的百分比。
，跨项目调用的库的 API 的百分比。
为了计算 usip 和 usil ，作者需要提取库API、项目方法和项目方法中的API调用。
- 266 (33.0%) 和 64 (7.9%) 项目分别有超过 20% 和 40% 的方法调用库 API
- 4,337 (60.0%) 个库最多有 2% 的 API 被跨项目调用
- 只有 281 (3.9%) 个库有超过 40% 的 API 跨项目调用
总结：项目通常对库 API 有适度的依赖，大多数库中只使用了很小一部分库 API。
使用过时度
作者从项目和库的角度定义使用过时度：
，项目中库依赖的平均使用过时度，
，库上的库依赖的平均使用过时度。
总结：几乎每个项目都采用过时的库，与最新版本的距离通常相当大。 需要有机制让项目开发人员意识到过时库的风险（例如，安全漏洞）或新版本的好处（例如，新功能）。
第三方库更新分析
更新强度
Summary. 尽管项目开发人员会更新库版本，但仍有一半的项目留下了超过一半的被采用的库从未更新过； 超过一半的使用它们的项目中有三分之一的库没有更新。
Summary. 更新库版本没有严格遵循语义版本控制，需要工具来分析在新版本发布之前是否引入了任何不兼容的更改，并建议遵循语义版本控制的正确版本号。
更新延迟
Summary. 项目开发人员对新的库版本反应迟缓。每次更新有一个较大的时间窗口，可能会增加使用过时库的风险（例如，安全漏洞），甚至会增加更新到新版本的难度，因为在此时间窗口内将使用更多的库 API。
第三方库风险分析
Summary. 超过一半的项目使用包含安全漏洞的库版本，三分之二的库版本包含安全漏洞。 安全漏洞的相对普遍存在表明，如果项目开发人员不了解已使用库中的安全漏洞或延迟库更新，项目面临的潜在风险。
结论
本文进行了一项定量和整体研究，以描述 Java 开源项目中第三方库的使用、更新和风险。
具体来说，从开源项目和第三方库的角度量化了使用和更新实践，分析了第三方库的安全漏洞风险。 在维护第三方库的问题和补救措施方面向开发人员和研究人员提供了启示。
文章地址：https://ieeexplore.ieee.org/document/9240619
github： https://3rdpartylibs.github.io
若有收获，就点个赞吧
0 人点赞
