简介

本文在“安全研究GoSSIP”公众号上首发。

老读者从首尔发回报道——11月17日到19日，第四十届软件工程领域国际会议ASE 2025在韩国首尔顺利举行。今年的ASE会议一共收到了1181篇投稿，最终录用了246篇论文。其中，来自中国的作者占比超过60%（含中国大陆及港澳台），体现了在软件工程领域的强劲实力。在所有提交和接收的论文中，研究主题的Top 3均为“AI和SE”、“测试和分析”、“安全及其他非功能特性”。

今天为大家推荐的论文是发表在这次ASE上的，一篇关于软件供应链漏洞影响评估的工作：Propagation-Based Vulnerability Impact Assessment for Software Supply Chains。该工作由新加坡国立大学梁振凯研究组完成并投稿。

随着软件生态变得日益复杂，软件供应链中的漏洞不仅影响漏洞所在的项目，还为依赖其所在项目的下游项目带来了安全风险——即使下游项目业务自身安全，攻击者还是能够通过利用这些上游漏洞来达到攻击下游项目的目的。因此，识别一个漏洞在软件供应链中的影响范围和规模变得越来越重要。

然而，现有工作并不能满足这一需求。一方面，已有研究要么不精确——只考虑了软件包层级（package-level）的依赖关系，没有进一步考虑漏洞所在函数是否真正可达，从而引入了大量虚假告警，要么是不完整的——通过在软件生态中采样等方式考察了局部或部分的函数调用图级（call-graph-level）依赖关系；另一方面，当前已被广泛采用的漏洞评估指标，如CVSS、CWE等，都只能用于对漏洞本身进行评估，而无法反映漏洞在软件供应链中的影响。

为了实现精确、完整的软件供应链漏洞影响评估，受程序分析中的数据流分析算法启发，论文首先提出了一个基于worklist并支持多层级剪枝的漏洞传播分析算法，能够精确、高效地在函数调用图层级、面向漏洞所在整个软件供应链生态实现漏洞传播分析。在此基础上，论文进一步提出了漏洞传播评分系统（Vulnerability Propagation Scoring System，简称VPSS），对漏洞传播分析结果进行建模，帮助人们对漏洞在软件生态中的影响进行量化和感知，支撑更加科学、及时的漏洞治理工作。

论文作者在Java Maven生态系统上实现了工具原型，并使用100个Maven生态中的漏洞进行了测试。评估结果显示，论文提出的算法能够完成全Maven生态的漏洞影响评估，相应的VPSS分数能够提供有价值的漏洞影响规模情报。

该论文的贡献主要包括：

• 设计了一种新的漏洞传播分析算法，实现在函数调用图层级、面向漏洞所在整个软件供应链生态识别受漏洞影响的下游依赖项目。
• 提出了漏洞传播评分系统（Vulnerability Propagation Scoring System，简称VPSS），这是第一个专门用于量化软件供应链中漏洞影响的动态评估指标。
• 在Java Maven生态系统上实现了算法和指标的工具原型，并使用100个Java Maven生态中的漏洞进行了测试。工具原型和用于测试的漏洞数据集已经开源。

背景

软件供应链安全已成为信息安全领域的焦点。一个上游库的漏洞（例如Heartbleed 或 Log4Shell ）就可能使其下游成千上万的软件项目处于风险之中 。因此，在漏洞被披露后，快速准确地评估其“影响范围”（Impact Scope）至关重要 。然而，现有的研究在尝试解决这个问题时，面临两大局限：

缺乏准确且完整的传播分析：

1. 粒度太粗：大多数分析停留在“包级别”（package-level）。它们只检查下游项目是否“声明”或包含了对脆弱包的依赖。但这会带来大量的假阳性（false positives），因为下游项目很可能只是依赖了那个包，却根本没有调用到漏洞所在的脆弱函数（vulnerable function，VF）。
2. 范围太窄：另一部分研究虽然尝试了更精确的“调用图”（call graph, CG）级别分析，但它们的能力非常受限——要么无法处理复杂的“全生态系统”依赖 ，要么只分析有限的下游项目 ，并且常常忽略了“传递性依赖”带来的深层风险。

作者进一步从六个方面衡量、对比了现有工作，并得出理想的漏洞传播分析应该具备的特性：

缺乏量化供应链“传播影响”的指标：例如，我们熟知的CVSS评分系统，是用来评估漏洞本身的固有特征（如攻击复杂度、所需权限等），但它无法衡量漏洞在供应链中的“传播影响”。一个CVSS 9.8分的漏洞，如果只存在于一个无人问津的库中，其真实的供应链风险可能远小于一个7.5分但存在于核心基础库中的漏洞。CVSS v4.0的官方FAQ也明确承认了CVSS不适用于衡量供应链的传播影响。

针对上述痛点，作者希望设计一个既准确（CG级别）又完整（全生态、传递性）的分析框架，并提出一个专门用于量化传播影响的新指标。

研究方法

为了实现这一目标，作者设计了一个包含四个步骤的语言无关的自动化漏洞影响评估框架，如下图所示：

一、依赖图构建 (Dependency Graph Construction)

首先，作者需要构建一个描述目标软件生态中全部依赖关系的依赖图。但如果直接构建“项目-版本”（PV）级别的图，规模将大到无法处理（例如Java Maven生态有超过1500万个PV ）。作者的关键洞察是：转而构建P-level（项目级别）的依赖图。这个图的规模要小得多（Maven中约66万个P ），可以作为高效的预过滤器 ，同时将具体的版本依赖信息（deps.json）用于后续的精确查询 。这个依赖图只需要构建一次，然后随着软件生态官方仓库做动态增量更新即可。

二、脆弱函数识别 (Vulnerable Function Identification)

为了进行CG级别的分析，我们必须首先知道“漏洞在哪几个函数里”。对此，作者采用了一种LLM辅助的优化策略 ：首先，使用传统的patch-based方法从补丁中提取候选的VF。然后，利用LLM（作者测试了GPT-4o-mini等模型）强大的代码语义理解能力，自动过滤掉那些与漏洞无关的修改，包括“语义等价的修改”（如重命名变量、增删空格或注释等）和“语义改变但无关的修改”（如增删日志（logging）代码等）。

三、漏洞传播分析 (Vulnerability Propagation Analysis)

这是作者提出的分析框架的核心。他们设计了一种新颖的“分层基于工作列表（Hierarchical Worklist-based）”的算法：

为什么用Worklist？论文的算法借鉴了数据流分析中的经典“工作列表”思想 。这使作者能系统地遍历整个生态依赖图，有效处理复杂的共享依赖，甚至是真实世界中存在的“循环依赖”问题 ，确保分析的健全性（soundness）。

为什么是Hierarchical（分层）？这是为了效率。直接对全生态构建CG进行分析是计算上不可行的 。作者设计了三级“分层剪枝（Hierarchical Pruning）”策略 ，逐层过滤掉海量的“假阳性”依赖关系：

• 版本剪枝（Version-based Pruning）：检查下游项目是否依赖了受影响的上游版本 。
• 导入剪枝（Import-based Pruning）：检查下游项目是否 真正导入（import）了上游包的内容 。在这一步，作者还通过识别“内在范围”（intrinsic scope），巧妙地处理了“fat JAR”等打包问题。
• CG级别剪枝（CG-level Pruning）： 最后，作者才对剩下的候选PV构建CG，检查下游项目是否真正调用了上游的脆弱入口点（entry-points）。

四、VPSS计算 (VPSS Calculation)

在精确分析完传播范围后，作者引入了一个全新的量化指标：VPSS（Vulnerability Propagation Scoring System），用于量化漏洞在供应链中的影响范围和演变。它和CVSS一样，采用0-10分制，并分为低、中、高、危急四个等级，易于理解和使用。注意，VPSS是“时间感知（Time-aware）”的，因此可以计算漏洞在任意时间点（例如t）的VPSS分数（计算时会排除t之后发布的P和PV），从而动态追踪其影响力的演变。

VPSS的核心公式是VPSS_raw = PBF x PDF，其中：

• PBF（传播广度因子）: 衡量漏洞传播的宽度。它综合考虑了受影响的下游P和PV的数量（包括直接和传递依赖）。
• PDF（传播深度因子）: 衡量漏洞传播的深度。它基于传播链的最大和平均长度来计算 。

详细的计算过程如下：

评估

作者在Java Maven软件生态上实现了分析框架的原型 ，并抽取了100个真实CVE进行评估 。

一、漏洞传播分析的有效性和可扩展性如何？

发现1：分层剪枝策略效果显著。在分析100个CVE的过程中，平均97.8%的项目（P）和99.2%的项目版本（PV）被成功剪枝。

发现2：假阳性比例大。如下图所示，如果仅基于依赖声明（即“initial”状态），平均一个漏洞会涉及上千个项目和数万个PV。而作者的分析（v3）最终确认，高达94.9%的PV是假阳性（即它们虽然依赖了，但根本没调用）。这大大降低了CG的构建成本 。

二、VPSS分数能告诉我们什么？

作者计算了这100个CVE在披露后24个月内（每30天一个快照，t0到t23）的VPSS分数演变。

发现1：VPSS能动态反映生态修复趋势。如下图所示，绝大多数漏洞的VPSS分数都随时间推移呈下降趋势。这完全符合预期：随着补丁被应用、下游项目逐渐迁移到安全版本，漏洞的实际传播影响在不断减小。

发现2：VPSS能捕获异常的“延迟更新”现象。作者也发现了一个有趣的特例：CVE-2016-3086的分数在t1时刻反而异常上升了（从6.95升至7.19）。作者推测这可能是由于下游项目“延迟更新”其依赖所导致的。

发现3：大部分漏洞的传播影响有限。如下面的箱线图所示，在100个CVE中，绝大多数的VPSS分数都保持在较低水平，并在两年内趋于稳定。

三、案例分析：CVE-2016-5393

CVE-2016-5393在测试数据集中VPSS得分最高（t0时为7.35）。作者分析发现，它在披露时直接影响了228个项目，并传递影响了另外154个项目。其最长传播链达到了7跳，并且在24个月后分数依然高达6.86，反映了生态中“长尾依赖”的顽固性。

论文链接：https://arxiv.org/pdf/2506.01342

VPSS开源项目链接：https://github.com/brant-ruan/vpss

作者团队十分欢迎大家交流合作，一起推动软件供应链漏洞治理工作！

作者信息

投稿作者简介：阮博男，2024级新加坡国立大学博士生，导师为梁振凯老师，目前主要研究方向为漏洞挖掘和漏洞评估，相关研究成果发表在ASE、USENIX Security、RAID等软件工程和信息安全领域的国际会议上，曾获得RAID 2024最佳实践论文奖和USENIX Security 2025杰出论文奖，也曾在BlackHat Asia、KCon、CIS等国内外知名工业界信息安全会议上发表演讲。

个人主页：https://profile.wohin.me

如果对NUS Curiosity Research Group感兴趣，梁振凯老师也在招收系统安全方向的博士生和博士后，详细信息可以参考：

梁振凯老师的个人主页：https://www.comp.nus.edu.sg/~liangzk

NUS Curiosity研究小组主页：https://nus-curiosity.github.io