开源软件已成为现代软件生态系统中不可或缺的基础构件。然而，随着组件库规模的持续扩大，其潜在的漏洞问题日益突显，对软件供应链安全构成了重大威胁。以Maven Central仓库为例，作为Java生态系统中使用最为广泛的组件库管理平台，其月度下载量达到37.8亿次，其中约3.97亿次的下载组件中存在漏洞。这些漏洞可能通过组件依赖链传播至下游项目，进而引发大规模的安全隐患。一个典型案例是Apache Log4j组件中的Log4Shell漏洞（CVE-2021-44228）。该漏洞影响了Maven Central中8%以上的Java组件，涉及组件数量高达35,863个[1]。根据Sonatype发布的2024年度软件供应链报告数据显示，即使在Log4Shell漏洞披露之后，仍有13%的Apache Log4j下载存在漏洞[2]。尽管新版本的组件能够有效修复这些漏洞，但由于开发者对版本升级后的兼容性存在顾虑等原因，导致80%的项目依赖一年以上未进行更新。值得关注的是，由于开发者对开源组件的漏洞影响范围的认知不足，约3.6%的依赖被升级至另一个同样存在漏洞的版本。

为应对开源组件漏洞引发的安全威胁，研究人员已经提出了多种分析与缓解方法。最常见的方法是基于软件成分分析的漏洞存在性检测方法，其通过提取项目依赖树并通过漏洞数据库匹配来识别潜在的漏洞组件。然而，由于这类方法未能考虑软件项目对漏洞函数的实际调用情况，导致较高的误报率。针对该局限性，研究人员提出了基于函数调用图的漏洞可达性分析方法，其通过构建软件项目的函数调用图来检测通向漏洞函数的潜在调用链。然而，这类方法仍然无法准确评估软件项目触发漏洞的实际可能性，因此依然存在误报问题。为了进一步解决误报，研究人员提出了组件漏洞的可触发性分析方法。这些方法使用漏洞组件的测试用例来引导软件项目的测试用例生成从而去触发组件漏洞。在软件项目直接调用漏洞函数的简单场景中，这些方法表现出色。然而，当软件项目通过调用链调用漏洞函数时，漏洞触发路径的复杂性显著增加，使得现有方法难以生成有效的漏洞触发测试用例。

以Apache commons-beanutils组件1.9.3版本为例，该组件版本受漏洞CVE-2019-10086影响。图2展示了CVE-2019-10086漏洞的触发样例，其中bean对象和“class”字符串构成了漏洞函数的触发上下文。

Apache commons-validator在1.7版本之前依赖了存在漏洞的Apache commons-beanutils组件。图3展示了通过Apache commons-validator分步触发CVE-2019-10086漏洞的过程。其中，Form.validate函数依次调用Field.validate函数、Field.getIndexedPropertySize函数，并最终调用PropertyUtils.getProperty函数。

在Field.getIndexedPropertySize函数调用PropertyUtils.getProperty函数过程中，要成功触发该漏洞，PropertyUtils.getProperty的第二个参数（即getIndexedListProperty的返回值）必须为“class”。这表明，getIndexedPropertySize函数的实例对象中，indexedListProperty字段的值必须设置为“class”。当该实例对象执行getIndexedPropertySize时，传递一个Object实例即可触发漏洞。在Field.validate调用Field.getIndexedPropertySize过程中，传递给getIndexedPropertySize的参数bean来自第43行代码中的params对象。params是validate函数的第一个参数，是一个Map对象，用于检索键为“java.lang.Object”的值。因此，为了通过validate函数触发该漏洞，params必须设置为{“java.lang.Object”: Object实例}，同时在validate函数执行到调用getIndexedPropertySize时，应保持此时的程序状态与getIndexedPropertySize触发漏洞时的程序状态一致。

为了评估该方法的有效性，复旦大学CodeWisdom团队进行了大规模的实验评估，我们收集了49个GitHub开源项目，包含84对“漏洞组件-项目”组合与182条可触发漏洞的函数调用链，函数调用链总长度为429。我们对比了目前的SOTA工具，如表1 所示，其中EPN（Exploited Pairs Number）表示工具在“漏洞组件-项目”组合中成功生成漏洞触发测试用例的组合对数量；ECN（Exploited Call Chains Number）表示工具成功生成的可触发调用链的数量；MEL（Maximum Exploited Length）表示工具成功生成的漏洞可触发调用链中的最大长度；AEL（Average Exploited Length）表示工具成功生成的漏洞可触发调用链的平均长度。Magneto成功为79个“漏洞组件-项目”组合生成漏洞触发测试用例，比SOTA方法提高75.6%；成功为135个可达调用链生成漏洞触发测试用例，比SOTA方法提高154.7%。

此外，我们还从调用链长度维度对工具的组件漏洞可触发性分析能力进行了定量分析。表2的前两列展示了基准数据集中182个可触发调用链的长度分布，后三列则分别报告了各工具成功触发的调用链长度分布情况。对于78个长度为1的可触发调用链，Transfer和Vesta展现出相对良好的有效性。Magneto在该场景中表现突出，仅有一例未能成功触发。对于调用链长度大于1的可触发调用链，Transfer和Vesta的性能出现显著下降，仅在少数案例中取得成功。Magneto由于使用了分步触发的策略，在复杂场景中仍保持了相对稳定的表现。