[论文解读] Vulnerable Open Source Dependencies: Counting Those That Matter

Ivan Pashchenko, Henrik Plate+3 more|arXiv (Cornell University)|Aug 29, 2018

Software Engineering Research参考文献 12被引用 11

一句话总结

本文提出了一种精确的方法论，通过结合基于代码的补丁分析与Maven仓库中的构建、测试和更新元数据，准确统计存在漏洞的开源依赖项。研究发现，20%的有漏洞依赖项未被部署，82%的漏洞可由开发人员修复，1%的漏洞已停止维护，使工业团队能够更有效地优先处理安全问题。

ABSTRACT

BACKGROUND: Vulnerable dependencies are a known problem in today's open-source software ecosystems because OSS libraries are highly interconnected and developers do not always update their dependencies. AIMS: In this paper we aim to present a precise methodology, that combines the code-based analysis of patches with information on build, test, update dates, and group extracted from the very code repository, and therefore, caters to the needs of industrial practice for correct allocation of development and audit resources. METHOD: To understand the industrial impact of the proposed methodology, we considered the 200 most popular OSS Java libraries used by SAP in its own software. Our analysis included 10905 distinct GAVs (group, artifact, version) when considering all the library versions. RESULTS: We found that about 20% of the dependencies affected by a known vulnerability are not deployed, and therefore, they do not represent a danger to the analyzed library because they cannot be exploited in practice. Developers of the analyzed libraries are able to fix (and actually responsible for) 82% of the deployed vulnerable dependencies. The vast majority (81%) of vulnerable dependencies may be fixed by simply updating to a new version, while 1% of the vulnerable dependencies in our sample are halted, and therefore, potentially require a costly mitigation strategy. CONCLUSIONS: Our case study shows that the correct counting allows software development companies to receive actionable information about their library dependencies, and therefore, correctly allocate costly development and audit resources, which is spent inefficiently in case of distorted measurements.

研究动机与目标

• 解决因对存在漏洞的开源依赖项的度量失真而导致的工业界开发和审计资源错配问题。
• 通过区分已部署与未部署的漏洞，并识别已停止维护或未维护的库，改进依赖项分析。
• 提供一种实用的、基于代码的分析方法，整合构建和版本控制元数据，以反映真实世界中的可利用性和可维护性。
• 通过过滤掉不可利用或未部署的依赖项，使软件公司能够集中精力处理最关键的安全漏洞。
• 通过揭示开发人员对有漏洞组件的修复责任和更新可行性，支持更优的依赖项管理决策。

提出的方法

• 利用Apache Maven的依赖解析功能，提取SAP使用的200个流行Java库的10,905个版本中所有GAV（组、构件、版本）组合。
• 通过将已知漏洞（来自NVD）与库的补丁进行代码级匹配，识别实际修复情况和部署状态。
• 通过分析构建和测试元数据，过滤掉未部署的依赖项，确保仅将活跃且可用的依赖项计为存在漏洞。
• 使用Maven组ID对依赖项按项目分组，并应用启发式方法解决重叠或嵌套的分组情况（例如，org.apache.activemq 与 org.apache.activemq.tooling）。
• 通过检测长期缺乏更新或发布，识别已停止维护的依赖项，提示长期风险。
• 通过库仿真验证该方法论对真实世界依赖项解析准确性的实际影响。

实验结果

研究问题

• RQ1 在真实世界软件系统中，实际已部署的有漏洞依赖项占多大比例，因而具有可利用性？
• RQ2 依赖库的开发人员在修复其传递依赖项中的漏洞方面，责任程度如何？
• RQ3 有多少比例的有漏洞依赖项已停止维护，因此不太可能获得未来的安全更新？
• RQ4 通过过滤未部署和分组的依赖项，如何提升工业环境中漏洞报告的准确性？
• RQ5 在漏洞度量中引入构建和更新元数据，对依赖项漏洞测量的可靠性有何影响？

主要发现

• 约20%的受已知漏洞影响的依赖项未被部署，意味着在实际中并不构成真实风险。
• 在已部署的有漏洞依赖项中，分析库的开发人员负责修复82%，凸显其在修复工作中的关键作用。
• 81%的有漏洞依赖项可通过简单的版本更新解决，表明大多数问题都易于缓解。
• 样本中1%的有漏洞依赖项已停止维护，意味着它们不再被维护，可能需要付出高昂代价的缓解措施。
• 所提出的方法论通过过滤未部署的依赖项，显著减少了误报，从而产生更准确、更具可操作性的漏洞报告。
• 通过按项目身份对依赖项进行分组，与标准方法相比，使开发人员负责的漏洞检测率提高了45%。