研究背景：开源漏洞质量至关重要
目前开源软件基数大、使用范围广，开发人员能够通过拷贝、二次开发源代码以及引入依赖组件等方式复用其它开源软件，构成了复杂且庞大的开源软件供应链。开源软件给开发人员带来便利的同时也引入了安全风险。根据新思科技2024年的供应链安全报告显示[1]，96%的代码库中包含开源代码，而84%的代码库中包含开源漏洞。
图1 新思科技 2024年度供应链安全报告
软件成分分析（SCA）技术是目前实现开源软件安全管理的有效方法之一。Gartner[2]评估了各个SCA供应商，包括Synopsys、Veracode、Snyk、Mend.io、GitHub和GitLab。这些供应商都维护着自己的漏洞数据库，建立了每个漏洞与其影响组件、影响组件版本、修复补丁之间的映射知识。为了使供应商能够提供有效的SCA服务，漏洞数据库需要持续更新，并保持准确。然而，目前漏洞数据库中关于漏洞影响组件的知识有着严重的质量问题，包括漏洞影响组件及其生态的漏报和误报，这会严重误导安全研究人员，并严重影响漏洞传播影响分析、漏洞修复、漏洞利用等下游分析工作的准确率。
以漏洞CVE-2021-22118 和 CVE-2017-1000163为例。如图2（左）所示，漏洞CVE-2021-22118的影响组件为org.springframework:spring-web。GitLab、Snyk和GitHub的漏洞数据库中关于该漏洞的影响组件信息存在不准确的情况。GitLab将spring-webflux标记为CVE-2021-22118 的影响组件，这是因为spring-webflux依赖于漏洞组件spring-web。类似地，Snyk将jenkins标记为CVE-2021-22118的影响组件，这是因为jenkins包含了漏洞组件spring-web。GitHub将spring-core标记为CVE-2021-22118的影响组件。然而，根据进一步的分析表明spring-core并未传递性依赖于spring-web，而且两者也不共享相似的漏洞代码片段。我们将此问题反馈给GitHub后，GitHub修复了该误报问题。如图2（右）所示，CVE-2017-1000163影响了位于NPM和Hex生态系统中的Phoenix框架。该漏洞影响组件在这两个生态系统中均被命名为phoenix。GitLab将NPM生态系统中的phoenix标记为影响组件。GitHub将Hex生态系统中的phoenix标记为影响组件。实际上，CVE-2017-1000163在两个生态系统中都影响phoenix组件，故GitLab和GitHub都未提供完整的生态系统信息。
图2 漏洞数据库质量问题示例
针对上述漏洞数据库的质量问题，复旦大学CodeWisdom团队深入分析了目前主流漏洞数据库（Snyk、Veracode、GitHub、GitLab）中各生态（Maven、NPM、PyPI、Go）的漏洞质量问题。如图3所示，漏洞影响组件及其生态知识的精确率范围为0.591至0.875和0.654至0.997，召回率范围为0.865至0.939和0.960至0.998。四个主流漏洞数据库在Maven生态系统中表现出最低的准确性。这些结果表明主流的漏洞数据库质量存在严重问题。
图3 漏洞数据库中关于漏洞影响组件及其生态知识的准确性评估结果
研究进展：基于多源知识的开源漏洞影响组件及其生态的识别方法
复旦大学CodeWisdom团队的开源风险治理平台 “伏羲”提出了一种基于多源知识的开源漏洞影响组件及其生态的识别方法Holmes，能够有效提升漏洞库质量，助力开源漏洞治理，相关研究论文“Identifying Affected Libraries and Their Ecosystems for Open Source Software Vulnerabilities”已发表于ICSE 2024。该工作的流程框架如图4所示，包括从多个信息源收集有关漏洞影响组件及其生态系统的多源证据；利用网络资源构建全量的生态组件池，并计算已收集证据与组件池中每个组件的相关性；将现有的CVE漏洞条目与其对应的影响组件及其生态作为训练数据集，训练开源漏洞影响组件及其生态识别器；输入待分析CVE漏洞条目进行全量组件相关度排序，取出全量排序中排名最高的组件与其对应的生态作为漏洞影响组件及其生态。
图4 Holmes的流程框架图
（一）漏洞证据搜集：收集CVE中的漏洞信息，以及CVE引用网站中的漏洞描述；根据CPE的供应商字段和产品名字段在GitHub中定位组件相关代码仓库的位置、组件相关的问题提交（Issue、Pull Request）和补丁（Commit）；基于规则在上述知识源中抽取漏洞影响组件相关证据，包括供应商和产品名称（vpn）：CPE配置中的供商名称和产品名称可能会直接揭示影响组件或提示影响组件的所属产品；产品版本（ver）：产品及其组件的版本通常共享相同的版本，CPE产品的版本范围可以缩小受影响组件的范围；组件坐标（lc）：代码存储库中包管理器的引用或包管理器配置文件中的包注册表URL可以揭示影响组件；文件路径（fp）：漏洞报告中提到的或代码存储库中修复提交所涉及的源代码文件的路径中可能包含影响组件；类名称（cn）：在漏洞描述中可能包含影响组件的相关类名；语言（lang）：代码仓库的语言信息表明影响组件的潜在生态。
（二）组件相关性计算：从面向Java的生态仓库（Maven仓库）、面向JavaScript的生态仓库（NPM仓库）、面向Python的生态仓库（PyPI仓库）和面向Go的生态仓库（Go仓库）中抓取组件的名称和组件版本以及对应的组件源代码，并以此构建关于这四个生态的全量组件库；解析组件库中每一个组件的所有类名、方法名、文件路径，并补充到组件库中；构建Lucene搜索引擎，查询数据库中的相关的组件元信息；通过改进的BM25算法[3]计算出每个组件的供应商和产品名称、产品版本、文件路径、类名称的相关性评分。
（三）漏洞组件排序：使用步骤（一）方法提取并处理漏洞影响组件的知识，使用步骤（二）方法为比较计算漏洞影响组件知识与所有组件的相关性度，并作为本步的输入；使用LambdaMart算法[4]进行漏洞影响组件的学习排序；使用训练完成的学习排序模型将组件数据库中的所有组件进行漏洞相关性排序，取出排名最高的组件为漏洞影响组件。
实验评估：助力开源漏洞质量增强
为了评估该方法的有效性，复旦大学CodeWisdom团队进行了大规模的实验评估，在Maven、NPM、PyPI和Go等四个生态系统上将Holmes与三个SOTA工具进行了对比分析。如图5所示，Holmes在 RO场景（训练集和测试集随机切分） 和 CO 场景（训练集和测试集按漏洞发布时间顺序切分）的所有四个生态系统中超过了所有的SOTA方法。具体而言，Holmes分别在 RO 和 CO 场景下的 mAP@1结果中，比最好的SOTA方法在识别影响组件上提高了 30.1% 和 62.7%。
图5 漏洞影响组件及其生态识别评估结果
为了进一步评估该方法的实用性，复旦大学CodeWisdom团队向各大漏洞数据库报告了所发现的漏洞影响组件与生态的质量问题，即通过发送电子邮件的方式向 Veracode 和 Snyk 报告了 81 和 40 个错误标注的漏洞影响组件与生态的质量问题，同时通过提交 Issue 的方式向 GitHub 和 GitLab 报告了 78 和 62 个错误标注的漏洞影响组件与生态的质量问题。GitLab 根据建议修复了48个问题，同时拒绝修复其中一个问题，因为该漏洞影响组件已从Maven中央仓库中删除，而其余的 13 个问题仍在确认中。GitHub根据建议修复了 62 个问题，并拒绝修复其中两个问题，而其余的14 个问题仍在确认中。此外，值得一提的是，GitLab 对帮助发现这些问题的工具表现出了兴趣。
关于“伏羲”
“伏羲”是复旦大学CodeWisdom团队推出的开源风险治理平台，旨在推动学术与合作交流，同时提高开源风险的治理水平。“伏羲”在高质量开源软件供应链知识（包括漏洞知识等）汇聚的基础上，利用高精度程序分析技术（包括代码差异分析、调用图分析等）实现多种开源软件供应链风险（包括安全风险、法律风险等）的分析与治理服务。目前“伏羲”提供了漏洞库、组件库等知识，以及漏洞传播影响分析、生态投毒检测等服务。“伏羲”将在漏洞质量增强方向持续攻关，打造高质量漏洞知识库。可以点击文末的“阅读原文”，跳转到开源风险治理平台“伏羲”进行体验和试用，也欢迎提出宝贵的意见和建议！
本文作者：吴苏晟、陈碧欢
往期回顾：
复旦CodeWisdom团队发布开源风险治理平台“伏羲”[1].Synopsys. 2023. Synopsys Software Composition Analysis. Retrieved July 14, 2023 from
https://www.synopsys.com/software-integrity/security-testing/softwarecomposition-analysis/knowledgebase.html
[2].Gartner. 2023. Gartner Magic Quadrant for Application Security Testing. Retrieved July 14, 2023 from
https://www.microfocus.com/en-us/assets/cyberres/ magic-quadrant-for-application-security-testing
[3]. Stephen Robertson, et al. 2009. The probabilistic relevance framework:
BM25 and beyond. Foundations and Trends in Information Retrieval 3, 4 (2009), 333–389.
[4]. Christopher JC Burges. 2010. From ranknet to lambdarank to lambdamart: An overview. Learning 11, 23-581 (2010), 81.
如有侵权请联系:admin#unsafe.sh