01 / 粒度
声明依赖会放大影响范围
依赖可能指向已修复版本；即使引入了受影响版本，也可能没有导入相关代码，或没有调用到漏洞函数。
依赖声明→调用可达
Vulnerability Propagation Scoring System
VPSS
沿调用路径
看见供应链影响
一个底层漏洞，究竟会影响哪些下游软件？VPSS 从依赖声明走向函数调用，在整个生态中追踪漏洞传播，再用传播广度、深度与时间快照刻画影响。
调用图级传播分析 / JAVA MAVEN / 0–10 动态评分
01 / 依赖不等于可达原创方法示意
↗
ASE 2025整个生态，细化到调用图
100
真实漏洞 / 论文评测集
660K P
项目级依赖图 / 约值
15M PV
Maven 项目版本 / 约值
01 / 为什么需要传播分析
依赖树里有它
不代表调用路径能到它
软件供应链影响不仅由漏洞本身决定，还取决于具体版本、实际使用的代码，以及下游软件不断变化的依赖。
02 / 规模
精细分析，也要走完整个生态
为每个项目版本直接构建调用图代价很高。项目级图先缩小范围，分层剪枝再把精细分析留给真正需要的候选。
→→→跨层级传播
03 / 时间
同一个漏洞，生态影响会变化
漏洞严重性与传播影响是不同维度。修复采用、旧依赖保留和生态增长都会改变影响快照；VPSS 为这个维度提供量化指标。
VPSS(t)
02 / 沿路径探索
从依赖候选
到可解释的传播影响
用小型示例观察候选剪枝、工作表汇合与循环，再用真实快照探索评分。浏览器展示离线数据，不运行现场 Maven 分析。
VPSS / 传播分析工作台交互演示 / 离线数据
分层剪枝 / 六个下游候选的缩小示例
← 在图内横向滚动 · 点击节点查看证据 →
漏洞源当前保留路径已排除候选
6 / 6下游候选 / 仅依赖声明
保留表示通过当前筛选，不等于已证实可利用。示例每个项目只有一个版本；论文分析分别维护项目 P 和版本 PV。
工作表 / 有新状态才重新入队
← 在图内横向滚动查看汇合与循环 →
待处理 →
独立的四项目示例，用有限目标函数集合演示汇合与循环；不与上一阶段的六候选图合并统计。
影响评分探索 / 真实时间快照的输入
PBF / 传播广度
PDF / 传播深度
先载入 CVE-2016-5393 的真实快照，再调整输入，观察广度与深度如何影响评分。编辑后得到假设场景；版本数不会少于项目数，平均路径不会超过最长路径。
03 / 方法背后的机制
用调用证据追踪传播
用图结构刻画影响
输入漏洞情报、修复补丁和依赖元数据，输出受影响的项目与版本、传播路径，以及指定时间快照的 VPSS。
I / 分层工作表分析
先缩小范围，再构建调用图
项目级依赖图用于发现候选。修复补丁生成漏洞函数候选，LLM 辅助过滤与漏洞无关的修改并提供理由供人工核验。之后，版本、导入和调用图三层剪枝逐步收紧传播范围，工作表追踪新增状态直到固定点。
P / PROJECTGroupId:ArtifactId
项目级图缩小查询范围
项目级图缩小查询范围
PV / RELEASE再加 Version
区分受影响的具体版本
区分受影响的具体版本
TF → EP目标函数到入口
连接跨项目调用路径
连接跨项目调用路径
静态调用图与漏洞版本情报都有准确性边界；反射、动态加载及不完整补丁可能影响结果。调用可达性仍不等同于成功利用。来源：§III、§VI-A。
II / 图感知的动态评分
广度、深度，以及时间快照
传播广度汇总直接与传递影响的 P / PV 占生态总量的比例，并对加权和进行对数缩放。传播深度结合最长与平均路径长度。两者相乘后，指数函数将结果映射到 0–10。
X = (Pdir / Ptotal, Ptrans / Ptotal,
PVdir / PVtotal, PVtrans / PVtotal)
PBF = ln(1 + γ · W Xᵀ)
PDF = 1 + (Lmax + Lavg) / (2Lnorm)
VPSS = 10(1 − exp(−PBF · PDF / k))
PVdir / PVtotal, PVtrans / PVtotal)
PBF = ln(1 + γ · W Xᵀ)
PDF = 1 + (Lmax + Lavg) / (2Lnorm)
VPSS = 10(1 − exp(−PBF · PDF / k))
权重与缩放参数由经验设定，会影响分数灵敏度。时间变化反映快照变化，不保证单调下降。来源：§III-E、§V-C、§VI-C。
04 / 来自论文的实验证据
把广泛依赖
收紧为调用级影响
100 个真实 Maven 漏洞的生态级评测。切换阶段，观察直接与传递依赖的平均候选数量如何收紧。这里展示论文图 6 的历史实测数据。
99.2%版本 PV 平均剪枝比例
项目 P 为 97.8%
项目 P 为 97.8%
来源：§V-B / 图 6
MCR 索引快照：2024-12-26
这些比例描述分析范围收紧，不是精确率或召回率。
1.5 h每漏洞分析时间中位数
5.2 h平均值 / 不含 JAR 下载
每个漏洞独立从头分析，耗时范围为 1.2 秒至 54 小时。结果受论文数据集与实验环境约束。
每漏洞平均候选数量
线性坐标 / 每行以该行初始值为 100% / P 与 PV 分别统计
论文没有测量初始图的最长与平均路径长度，因为计算成本过高。v1、v2、v3 的路径长度仅比较已剪枝图。
查看图 6 与实验条件 ↗案例 / CVE-2016-5393
修复出现后
传播影响仍可能长尾保留
Hadoop Common 的漏洞在 t₀ 直接影响 228 个项目，并传递影响另外 154 个项目。论文报告最长路径为 7，贯穿 Hadoop 与 Hive 组件。在 24 个观测点中，VPSS 从 7.35 缓慢降至 6.86。受影响版本数量却增长，生态规模增长使相对份额下降。
来源：§V-D / 图 8，以及仓库 vpss_stats 原始统计
t₀ 为 NVD 披露时点；t₂₃ 为第 23 个 30 天间隔（690 天）。每个点均为原始记录；折线只连接采样点。
7.35高传播影响
05 / 回到原始资料
Propagation-Based Vulnerability Impact Assessment for Software Supply Chains
40th IEEE/ACM International Conference on Automated Software Engineering · ASE 2025 · pp. 65–77
@inproceedings{ruan2025vpss,
title={Propagation-Based Vulnerability Impact Assessment for Software Supply Chains},
author={Ruan, Bonan and Lin, Zhiwei and Liu, Jiahao and Zhang, Chuqi and Ji, Kaihang and Liang, Zhenkai},
booktitle={Proceedings of the 40th IEEE/ACM International Conference on Automated Software Engineering},
pages={65--77},
year={2025},
doi={10.1109/ASE63991.2025.00014}
}