【论文分享】从噪声到信号：如何在千万级软件包中精准定位漏洞影响？
想象这样一个场景：你是一名开发者，每天打开 CI/CD 系统，迎接你的是数百条安全警报——”检测到依赖包存在高危漏洞，请立即修复！” 但当你花费大量时间逐一排查后却发现，绝大多数警报都是虚惊一场：那些所谓的”漏洞代码” 根本就没有被你的应用调用。这种”警报疲劳”已成为软件供应链安全领域的痛点，也是众多安全检测工具难以实际落地应用的重要原因。 这正是奇安信技术研究院和清华大学研究团队在 NDSS 2026 会议上发表的论文所要解决的核心问题。论文题目为《From Noise to Signal: Precisely Identify Affected Packages of Known Vulnerabilities in npm Ecosystem》，作者为蒲应元（奇安信星图实验室），应凌云博士（奇安信星图实验室）和谷雅聪博士（清华大学）。这项研究针对全球最大的开源软件生态系统——npm（拥有超过 300 万个包，2024 年处理了约 4.5 万亿次请求），提出了一套基于函数调用关系的细粒度漏洞传播关系识别方法和分析框架。论文分析结果表明，传统工具所产生的漏洞警告中，高达 68.28% 都是”噪声”，即漏洞代码实际上根本无法被触达。 npm生态系统的复杂性源于其极度碎片化的包依赖结构。已有研究显示，约四分之一的npm包版本依赖于存在已知漏洞的包。以 理论上，函数级可达性分析是最佳解决方案——只有当存在从应用入口到漏洞函数的调用路径时，才认为应用真正可能受到影响。但在 npm 生态实施函数级分析面临三大技术挑战： 面对这些挑战，我们设计并实现了 VulTracer 这个分析框架。它的核心洞察在于：npm包一旦发布就不可变，因此可以为每个包预计算可复用的分析结果。这开启了”分析一次，复用多次”的新范式。 VulTracer 将传统的整体式分析分解为三个独立阶段，核心设计和架构如上图所示。以下将详细介绍每一个部分的设计逻辑和细节。 首先，VulTracer 利用程序静态分析技术，为每一个包构建了一个富语义图（Rich Semantic Graph, RSG）。这张图不仅看清了包内部的函数调用脉络，更关键的是，它显式地刻画了包的“边界”——哪些函数被暴露给了外部，又有哪些地方调用了外部依赖。传统的调用图（Call Graph）只记录”谁调用了谁”，而RSG设计了一个多层次的图结构，完整保留包的边界信息，图中的实体结构和详细定义如 下图 DEF1 所示，包含了三类不同的顶点集合和边集合。 虽然 RSG 保留了包的全部内部细节，但如何让独立分析的包能够正确”对接”？这就涉及到了提取形式化的接口契约。VulTracer 从这张复杂的图中提取出了一份简洁的形式化接口契约（Interface Contract）。这就像是给每个软件模块定义了标准的“插头”和“插座”，契约中清晰地记录了 API 的导出方式（Export Manifold）和导入方式（Import Manifest）。这一步至关重要，它充当了一道“语义防火墙”，屏蔽了复杂的内部实现细节，只保留了交互所需的关键信息。具体的定义如下图DEF2 所示。 最后，当需要检测某个具体项目时，VulTracer 不再需要深究源代码，而是像拼乐高积木一样，根据依赖关系，将预先计算好的 RSG 和契约进行组合式合成（Compositional Synthesis）形成一个新的生态级调用图 (ECG)。并且该 ECG 可根据任意真实项目的依赖关系按需组装。这种设计使得分析速度和扩展性得到了质的飞跃——在处理复杂的真实依赖图时，VulTracer 的成功率高达 99.41%，而对比的工具Jelly仅为 37.37%。 在这项工作中，我们利用 VulTracer 对整个 npm 生态进行了史上最大规模的函数级漏洞传播影响分析。 首先我们构建了两个核心的数据集： 我们首先聚焦于d₁ → d₀的单跳关系，这样可以排除多跳传播的复杂因素，精确归因。在我们的研究中建立了三层漏洞传播条件：仅引入模块 (C_mod)、调用任意函数 (C_func)、调用漏洞函数 (C_vuln_func)。定义如下图所示： 只有 C_mod ∧ C_func ∧ C_vuln_func 同时为真，才认为漏洞真正传播。最终单跳的分析结果如下表所示。 我们发现平均 22.80% 的直接依赖包声明了依赖，但从未导入任何模块（C_mod失败）。以 lodash 为例：存在 396,112 个声明依赖的包，但是有 131,933个”僵尸依赖” (33.31%)。这13万多个包背上了”有漏洞”的标签，但实际上完全不受影响。同时我们还发现，npm 第三方库的 API 设计决定传播率。同样的对于 lodash 这样一个综合工具库，拥有242个函数，但漏洞函数 template 只占所有调用的0.30%，排名第49位，详细分析如下图所示。说明这个函数的下游使用率并不高。与之相反的是 debug 库，它功能单一专注于调试，其核心功能函数就是其主函数，导致直接依赖者的受影响比例高达 71.77%。 单跳分析揭示了初始衰减，但漏洞会通过传递依赖传播多远？我们追踪了完整的传播路径。在分析中，我们追踪了9,868,514条潜在传播路径，涉及1,663,634个包版本。 最终不同漏洞的传播结果如下表所示。 在表格数据中， 以 CVE-2022-3517 (minimatch) 为例，数据揭示了粗粒度分析带来的严重误报问题。包级别分析报告了 497,595 条潜在传播路径，涉及 286,731 个受影响的包版本。然而，经由 VulTracer 的函数级可达性分析，确证受影响的包版本仅为 22,557 个。从全局统计维度来看，函数级分析所识别的受影响库数量平均仅为包级别分析结果的 31.72% 。这一数据统计表明，现有包级别依赖扫描工具产生的警报中，约 68.28% 属于漏洞代码不可达的误报（False Positives）。 最后，在上图也更进一步可视化了漏洞传播随依赖链路深度的衰减过程，分别从两个不同的视角来进行呈现。图（a）展示了每一跳（Hop）中新增受影响包数量的分布情况。对比显示，函数级别（红色曲线）的传播在 3 跳之后呈现出急剧的衰减趋势，与包级别（蓝色曲线）的长尾分布形成显著差异。这证实了真实的漏洞影响范围会随着依赖深度的增加而迅速减弱。而图 （b） 展示了传播过程中的累积概率分布情况进一步佐证了这一“浅层效应”：函数级传播曲线迅速收敛并达到平台期，数据显示 96.59% 的真实受影响包均收敛在 4 跳 的范围内。这意味着，尽管依赖图谱可能具有较深的层级结构，但具有实际威胁的漏洞传播主要局限于浅层依赖网络中。 面对日益复杂的开源生态，我们的研究证明，传统的“版本比对”模式已经难以为继。由现有包级别工具识别出的潜在风险中，高达 68.28% 的漏洞代码实际上从未被调用 。换言之，近七成的“受影响”项目其实是安全的，并不需要火急火燎地去修复。这种高误报率不仅制造了巨大的“噪声”，更导致了严重的警报疲劳，反而掩盖了真正的威胁。因此，转向更细粒度的函数级可达性分析已是行业必经之路。通过 VulTracer，我们可以从噪声中提取出那 30% 的真实信号。这不仅能让开发者从无效的运维工作中解脱出来，更能让安全团队聚焦于真正具有可利用性的威胁。这才是让供应链安全治理走出困境、迈向精准防御的未来方向 。一、引言：软件供应链安全的”狼来了”困境
二、问题的本质：为什么传统方法会产生如此高的误报？
pac-resolver为例，这个每周下载量达 300 万次的 npm 包曾曝出高危远程代码执行漏洞，导致 GitHub 上超过 28.5 万个公共仓库可能面临风险。但问题的关键在于：依赖存在漏洞的包，不等于你的应用真的受到影响。当前主流的软件成分分析（SCA）工具，如npm audit、GitHub Dependabot等，都采用包级别的分析方法。它们的逻辑很简单：如果你的依赖树中存在包A的v1.0版本，并且包A的v1.0版本存在漏洞，则发出警报提醒你的应用受到影响。 但这种粗粒度分析忽略了三个关键问题：// 动态属性访问
obj[propName](); // propName是变量，静态分析难以确定调用目标
// 高阶函数
function process(callback) {
callback(); // 不知道传入的是哪个函数
}
// 原型链动态修改 ，增加了分析的不确定性
Object.prototype.newMethod = function() { ... }; 三、VulTracer的核心设计和解决方案
3.1 富语义图生成 (RSG Generation)
3.2 接口契约提取 (Interface Contract Extraction)
3.3 拓扑排序驱动的按需组合式合成 (Compositional Synthesis)
四、生态级实证研究：揭示漏洞传播的真相
4.1 数据集构建
4.2 单跳分析：分析衰减的根本原因
4.3 多跳分析：揭示传递性衰减规律
五、结论：从噪声中提取信号