现代软件系统的开发越来越依赖于生态系统中的开源软件。最新的研究表明，大约35%的开源项目代码来自其依赖的第三方库。不幸的是，开源库经常受到各种安全漏洞的威胁，而公开的漏洞数量在近年来稳步增加。这些漏洞可能对整个生态系统构成重大的安全威胁。针对该问题，近年来研究人员提出了许多软件成分分析（SCA）工具，旨在检测出包含已知安全漏洞的第三方库或者组件。然而，最近的研究报告表明，这些工具经常会产生大量的误报。其中，高达73.3%依赖于漏洞库的开源软件实际上是安全的，即不受其中所含漏洞的影响。为了设计更精确的工具，全面地理解生态系统中的漏洞威胁是十分重要和迫切的。为弥补这一缺陷，本文基于大量数据集，开展了全面的实证研究来分析和理解Java生态系统中已知漏洞的跨项目安全威胁。本实证研究在多个方面做出了有趣而重要的发现，包括漏洞的可达性，可达路径的复杂性，以及下游项目和开发人员对上游漏洞的不同处理方式等。这些发现不仅可以提供对Maven生态系统中上游安全漏洞威胁程度的全面理解，同时也可以促进未来相关领域的研究工作。
该成果“Understanding the Threats of Upstream Vulnerabilities to Downstream Projects in the Maven Ecosystem ”已被CCF列表A类会议“ACM/IEEE International Conference on Software Engineering(ICSE)”录用。ACM/IEEE ICSE是软件工程领域最权威的国际学术会议之一，主要关注软件开发和维护、软件测试和验证、软件项目管理等前沿研究。ICSE 2023共收到796篇投稿，最终接收209篇文章，接收率为26%。
论文链接：https://ieeexplore.ieee.org/abstract/document/10172868
背景与动机
Java的广泛流行很大程度上归功于其完善的开源生态管理工具Maven以及积极贡献各种第三方库（TPL）的开发者。Maven是最被广泛采用的Java第三方库管理工具，已经索引了超过951万个Java库，每个库都有一个唯一的标识符（GAV）, 开发者可以通过在配置文件中指定GAV来方便地使用这些包。
Java第三方库的广泛使用也带来了不可忽视的安全威胁。例如最近开源项目Apache Log4j2中的安全漏洞CVE-2021-44228影响超过35,000个Java包，大约占 整个Maven生态系统的8%，所以精确的分析与评估第三方库中漏洞的安全风险与威胁是十分重要的。如今已有许多成熟的软件成分分析（SCA）工具，例如OWASP DC、Snyk和Github Dependabot等，来检测第三方库中的已知漏洞并对开发者进行预警。这些工具的主要思想是基于名称和版本的匹配。然而，依赖有漏洞的库并不一定意味着就会受到其影响，而且没有必要的软件升级/降级可能会引入依赖冲突或兼容性问题。下图展示了一个实际的例子:
图1 包含漏洞的上游软件commons-io以及它的四个下游软件
本文以在commons-io项目中的CVE-2021-29425漏洞为例来展示上游软件漏洞对下游的影响。该漏洞影响commons-io的2.7及以下版本。它是由于开发人员忘记在getPrefixLength()函数中检查有效主机名，从而有很高的可能性引入路径遍历漏洞。commons-io作为一个上游项目，已经被Maven中的23,974个其他项目（称为下游项目）使用，其中超过14,000个使用的是受CVE-2021-29425影响的版本。拿受该漏洞影响的2.4版本来说，commons-io就被4,386个不同的下游项目使用。图1中显示了这些下游项目的四个例子。通过手动分析这个漏洞和相应的受影响下游项目，可以得到以下发现：
首先，依赖包含漏洞的上游软件中的一些下游项目实际上可能并未受到该漏洞的威胁。如图1所示，尽管所有四个下游项目都依赖于commons-io的漏洞版本（即，版本2.4），但并非所有项目都能实际触发到漏洞函数。对于开源项目pmd-core和openhub-core来说，它们可以通过接触到存在漏洞的getPrefixLength()函数。相反，其他两个项目（即，github-api和runtime-domain-sqlg）无论如何都无法接触到漏洞函数。如前所述的工具会报告所有的下游项目都是受影响的，因为它们忽略了漏洞代码的可达性，从而导致了误报。
其次，即使漏洞函数可以被下游项目调用，其被利用的机会也不尽相同。图1中显示了可以接触漏洞函数的两个项目的调用图。可以发现，下游项目是通过其他API（如equalsNormalized()和concat()）间接调用漏洞函数的。例如，对于pmd-core，它通过其他四个函数来接触漏洞函数，而openhub-core只通过一个。除了路径上通过函数的数量上的区别，在一条调用路径上，需要满足的约束也是不同的。比如，pmd-core需要满足三个约束，即filename1!=null，filename2!=null和size!=0。相反，对于openhub-core项目，一旦可以触发对concat()的调用，它就可以直接接触到漏洞的函数，而无需满足任何约束。这些路径上的约束限制了下游项目中的漏洞利用，因此它们的复杂性可以反映出下游项目受到漏洞威胁的程度。
除了软件本身，实证研究发现下游开发者对上游漏洞所采取的措施也大相径庭。如前所述，openhub-core项目可以直接访问CVE-2021-29425的漏洞函数，路径上没有其他限制。本文观察到该项目的2.3.0版本中，已将依赖的commons-io版本从2.4直接升级到2.7。然而，对于同样可以访问漏洞函数的pmd-core项目，其开发者并未采取任何行动。相反，github-api项目虽然无法访问漏洞函数，却已将依赖版本从2.4升级到2.8。我们观察到，这些行为及其背后的成因并不理所当然，针对这个情况，本文对这种下游对上游漏洞的措施及其成因进行了系统性的调研。
受此启发，本研究希望对整个Maven生态系统中的已知漏洞开展跨项目分析，以全面的了解上游漏洞的可达性、威胁程度以及下游开发者如何应对上游项目中的漏洞。
数据收集
为了得到Maven的跨项目漏洞安全威胁的“全景图”，本研究构建了一个已知的开源项目漏洞数据集，并基于此展开了大规模的实证研究。为了保证结果的准确性，该数据集应满足以下准则：
首先，应该有相应的漏洞补丁，因为需要补丁来识别漏洞函数，这些用于从下游项目的角度调查这些漏洞的可达性。
其次，漏洞项目应该被Maven索引，这可以被其他下游项目用作上游项目。
第三，漏洞上游应该被足够多的下游项目所使用，避免极端情况带来的偏差。
根据以上标准，本文最终构建了一个基准数据集（具体步骤请参考原文），具体包含了832个CVE和1,078个补丁，对应到Maven中613个不同的上游软件。平均而言，对于每个上游，收集了52个不同的下游项目，从而形成了44,450个
图2 标准数据集的基本统计信息
实验结果
本研究主要在以下几个方面开展了实证研究。
1）漏洞函数的可达性
图3 下游所受影响比例及TOP-10高频API可达漏洞函数的比例
图3回答了有关漏洞函数可达性的问题，可以看到，其中大约25%的漏洞上游项目中的漏洞函数会被相应的下游项目所接触。其中，我们发现一些热点函数（常用API）若是能到达漏洞函数的话，则会导致大量的下游项目变得易受攻击，这值得引起开发者更多的关注以确保生态系统的安全。
2）漏洞函数可达路径特征
图4 可达路径上调用函数的数量与路径约束的数量
图5 下游调用点位置的调用情况分布
图4，图5展示了漏洞函数可达路径上的细节信息。由图4可以看出，42.7%的可达CG路径长度小于5。对于大约30%的这样的路径，至少需要解决10个约束才能到达漏洞函数。本研究对漏洞函数的下游调用点细节进行了进一步分析，图5中，G代表该调用点是否存在诸如输入检查的checker进行保护，R和P分别表示是否会以返回值或者参数形式将漏洞函数结果进一步传播，我们发现大约一半的风险调用没有受到任何检查保护，近30%的风险调用的返回值将会传播，可能会造成进一步的安全威胁。
3）下游开发者反应
图6 下游开发者对于漏洞的反应速度热力图
本研究首先对下游开发的反应获取了一个概览图，了解下游项目如何受到上游漏洞的影响，以及它们在软件演变过程中如何应对。对于每个三元组，提取下游配置中指定的上游版本，以查看它是否受到特定CVE的影响。然后，跟踪下游中指定的版本，看看它们在软件演变过程中是否发生变化。图6上面部分显示了两个受影响的下游项目的例子，switcher-client和expense-tally-model，它们是上游log4j-core的下游，黄色部分代表仍在使用log4j, 黑线代表CVE发布时间。对于这样的实例，本研究在整个标准数据集上大规模实现了一遍，如图6下半部分所示（由于黄色堆积，导致图中出现红色部分），结果表明86%的下游在270天内对漏洞上游采取了行动。
图7 下游开发人员采取/不采取行动的原因分析
本文接下来对开发者的动机和一些主观性行为进行调研，图7中的实验结果表明，大多数的下游开发者（67.0%）由于广泛采用了SCA工具，所以知道上游存在的漏洞。大多数下游项目不对上游的漏洞做出反应，是因为项目没有受到影响或者没有得到维护。上游的漏洞可能由于其他非安全的原因而被偶然解决，比如日常升级和解决兼容性问题。
总结
本文针对Maven系统中的跨项目漏洞进行了系统性的分析，收集到目前最大的跨项目漏洞数据集，并得到了一系列结论。实验结果可以帮助改进现有的SCA工具，并为生态系统中漏洞研究的未来发展提供支持和分析角度，具体来说：
1）对下游开发者：现有的SCA工具并不精确，会产生许多误报。大多数上游漏洞函数实际上并不能被相应的下游项目所触及。然而，现有的SCA工具仍会生成警报，从而导致误报。因此，建议下游开发者进行进一步的分析（例如，可达性分析）以评估这些漏洞的威胁，然后再采取如升级等行动。
2）对上游开发者：如果不知道漏洞代码和相应的补丁，很难准确评估一个漏洞对其他项目的威胁。因此，如果上游开发者能够更好地管理和跟踪包含的漏洞，并为下游提供详细信息（例如，漏洞函数和触发条件），那么将有利于SCA工具进行更精确的分析。此外，有许多流行且常用的API经常导致下游项目引向上游漏洞函数。因此，上游开发者也应更加关注这些API（例如，添加更严格的检查器），以缓解对下游项目和整个生态系统的安全威胁。
3）对相关的研究者：精确评估漏洞风险以及版本升级的附带成本的模型是非常需要的。然而，现有的在包级别进行粗粒度分析的工作无法实现这样的目标，而本研究的实验结果和发现可以为构建威胁评估模型（例如，利用沿着漏洞传播路径的约束特性）提供实际的指导。
详细内容请参见：
Yulun Wu, Zeliang Yu, Ming Wen, Qiang Li, Deqing Zou, and Hai Jin. "Understanding the Threats of Upstream Vulnerabilities to Downstream Projects in the Maven Ecosystem." In Proceedings of IEEE/ACM 45th International Conference on Software Engineering (ICSE), pp. 1046-1058. IEEE, 2023. https://ieeexplore.ieee.org/document/10172868
声明：本文来自穿过丛林，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
