💻 computer science

Original Sin of npm: A Study on Vulnerability Propagation in JavaScript Dependency Networks

该论文基于对 npm 生态中超过 100 万个软件包及其依赖网络的分析，揭示了少数易受攻击的包导致了大量衍生包存在漏洞的“原罪”现象，指出近四分之一的项目受此影响且修复周期长达近五年，并据此提出了针对性的缓解建议。

原作者： Michael Robinson, Sajal Halder, Muhammad Ejaz Ahmed, Muhammad Ikram, Seyit Camtepe, Hyoungshick Kim

发布于 2026-04-21

📖 1 分钟阅读☕ 轻松阅读

原作者： Michael Robinson, Sajal Halder, Muhammad Ejaz Ahmed, Muhammad Ikram, Seyit Camtepe, Hyoungshick Kim

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文就像是在给软件世界做一次“全身体检”，专门检查了 JavaScript 编程语言中最流行的“零件库”——npm。

想象一下，开发软件就像盖房子。以前，建筑师（程序员）需要自己烧砖、做门窗（自己写所有代码）。但现在，大家习惯去一个巨大的乐高超市（npm）里买现成的积木块（软件包）来拼房子。这确实让盖房子快多了，但也带来了一个巨大的隐患：如果你买的一块积木本身有裂缝（漏洞），那么所有用这块积木盖出来的房子，也都会有裂缝。

这篇论文就是去调查这个“乐高超市”里，到底有多少裂缝，它们是怎么传播的，以及为什么修好它们这么难。

以下是用通俗语言对论文核心内容的解读：

1. 核心发现：少数“坏积木”搞垮了大半壁江山

研究发现，npm 里有超过 100 万个 积木包。其中，21.6% 的积木包（也就是超过 23 万个）都带着“裂缝”（漏洞）。

最惊人的是，这些裂缝并不是均匀分布的。

二八定律的极端版：只有 23 个 最坏的“坏积木”（特定的漏洞），就导致了 50% 的所有安全问题。
比喻：就像超市里只有 23 种牌子的螺丝是生锈的，结果导致超市里一半的家具（软件）都因为用了这些螺丝而摇摇欲坠。只要修好这 23 种螺丝，就能解决一半的问题。

2. 传播链条：多米诺骨牌效应

软件包之间是互相依赖的。

直接依赖：你直接买的积木。
间接依赖：你买的积木里，又包含了别人买的积木。

论文发现，61% 的积木包都依赖了其他积木。这意味着，如果最底层的一个小积木坏了，它会像多米诺骨牌一样，一层层传上去，导致成千上万个上层软件都受影响。

数据：平均每个受影响的积木包，会连累 3.6 个其他积木包。这种“一损俱损”的连锁反应非常可怕。

3. 时间线：修修补补太慢了

这是论文最让人“扎心”的发现：

发现漏洞到公开：平均要等 近 6 年（71 个月）才会被正式记录在案。
从发布到修复：平均要等 近 5 年（59 个月）才能修好。

但是，这里有个有趣的反转：
虽然修好一个漏洞平均要花 5 年，但大多数（83%）的漏洞其实在被“公开曝光”之前，就已经被悄悄修好了。

比喻：就像你家窗户破了，邻居（黑客）还没发现，你其实已经悄悄换好玻璃了。但是，因为没人正式宣布“窗户修好了”，大家还以为窗户是破的，或者还在用旧玻璃。
问题：虽然修好了，但大家更新得太慢。很多软件明明有新版（修好的），却还在用旧版（破的），导致风险一直存在。

4. 为什么会有这么多漏洞？

过度依赖：现在的软件太复杂了，一个软件可能引用了成百上千个其他软件。依赖越深，风险越大。
老旧代码：很多软件还在用几年前的旧版本，就像还在用 Windows 95 一样，充满了已知漏洞。
发现速度赶不上增长：虽然发现漏洞的速度在变快，但新软件包产生的速度更快，导致漏洞总数像直线一样不断上升。

5. 给开发者和用户的建议（如何自救）

论文最后给出了一些“生活小贴士”：

少买“杂牌”积木：尽量减少不必要的依赖，只保留真正需要的。
定期大扫除：不要一直用旧版本，要定期清理和更新依赖包。
关注“核心”漏洞：既然 23 个漏洞占了 50% 的问题，那么优先修复这 23 个，性价比最高。
别等官方通知：既然很多漏洞在公开前就修好了，开发者应该更主动地去检查更新，而不是等新闻出来才行动。

总结

这篇论文告诉我们：npm 这个巨大的软件生态系统，就像一座由无数乐高积木搭成的摩天大楼。 虽然建得很快很漂亮，但因为用了太多有裂缝的底层积木，导致整栋楼都在晃动。

好消息是，我们找到了最关键的 23 个裂缝，只要集中力量修补它们，就能让大楼稳固一大半。坏消息是，大家更新和修补的速度太慢了，而且很多人还在用“旧图纸”盖房子。

一句话总结：软件依赖就像借东西，借得越多，风险越大；只有少借、勤还（更新）、并盯着那几个最坏的“债主”（高频漏洞），才能睡得安稳。

1. 研究背景与问题定义 (Problem Statement)

背景：随着开源软件（OSS）的普及，Node Package Manager (npm) 已成为 JavaScript 生态系统的核心，托管了数百万个包。现代开发高度依赖复用现有库，导致复杂的依赖网络（Dependency Networks）形成。
核心问题：
- 漏洞继承（Vulnerability Inheritance）：父包（Parent Package）通过直接或间接依赖引用其他包，从而继承这些依赖包中的安全漏洞。
- 传播机制不明：现有的研究多关注直接依赖或静态分析，缺乏对**多层级传递性依赖（Transitive Dependencies）**中漏洞传播路径、速度及影响范围的系统性量化分析。
- 响应滞后：从漏洞被发现、发布到修复（Patch）的时间周期（Time-to-Fix）以及披露（Disclosure）的时效性尚不明确，导致大量软件长期处于暴露状态。
研究目标：量化 npm 生态系统中漏洞的传播模式，分析漏洞披露与修复的时间线，并识别导致大规模漏洞传播的关键因素。

2. 研究方法论 (Methodology)

本研究构建了一个大规模、结构化的漏洞数据库，并采用了生存分析（Survival Analysis）等统计方法。

数据来源：
- 包数据：基于 npm-follower 项目，随机抽取了 1,077,946 个唯一的 npm 父包（约占当时生态系统的 1/4）。
- 依赖网络：利用 Google 的 deps.dev API 构建完整的依赖图，区分直接依赖和间接（传递性）依赖。
- 漏洞数据：通过 Google Open Source Vulnerability (OSV) API 和 NVD (National Vulnerability Database) API 获取 CVE 信息、CVSS 评分及修复日期。
数据处理：
- 清洗数据，剔除已弃用或不可用的包。
- 将包元数据、依赖关系、CVE 标识符、CVSS 评分（v3.x）以及时序数据（发布日期、修复日期）进行关联，构建了包含 27 个特征的漏洞数据库。
分析方法：
- 生存分析（Survival Analysis）：使用 Kaplan-Meier 估计器处理右截断数据（Right-censored data），计算漏洞从“首次受影响版本发布”到“公开披露”或“修复”的中位时间。
- 回归分析：评估漏洞数量随时间增长的线性或指数趋势（ $R^2$ 值）。
- 网络分析：分析依赖深度、依赖数量与漏洞传播范围的相关性。

3. 关键发现与结果 (Key Findings & Results)

3.1 漏洞披露与发布特性 (RQ1)

线性增长：自 2015 年以来，npm 上的漏洞数量和受影响包的数量均呈线性增长趋势（ $R^2$ 分别为 0.97 和 0.96），而非指数爆炸。
严重程度分布：在 1,498 个唯一漏洞中，42% 为“高”（High）危，26% 为“严重”（Critical），仅 0.5% 为“低”危。
披露滞后严重：从漏洞版本首次上传到 npm 到其在 OSV/NVD 上公开披露，中位时间长达 71 个月（约 6 年）。这表明漏洞在公开前已在生态系统中潜伏了极长时间。
披露顺序异常：研究发现 83.1% 的漏洞在公开披露之前就已经有了修复版本（中位偏移量为 -19 天），说明开发者倾向于先修复再披露，但披露机制本身存在巨大延迟。

3.2 漏洞修复效率 (RQ2)

修复周期漫长：从第一个受影响版本发布到修复版本可用，中位时间约为 59 个月（4 年 11 个月）。
修复与披露的时间差：尽管修复通常早于披露，但下游用户采纳修复版本的速度极慢。许多包在修复发布后数年仍在使用旧版本。
结论：生态系统的主要风险并非“修复发布慢”，而是“补丁采纳慢”以及“披露机制滞后”。

3.3 漏洞传播特征与集中度 (RQ3)

帕累托分布（二八定律）：
- 7 个 最常见的 CVE 导致了 25% 的漏洞实例。
- 23 个 最常见的 CVE 导致了 50% 的漏洞实例。
- 其中，CVE-2023-44270 单个漏洞影响了 24,882 个包，占总漏洞实例的 8.34%。
依赖网络深度：
- 61.3% 的包拥有依赖项，这些包承载了 94.2% 的漏洞。
- 无依赖的独立包漏洞率极低。
- 受影响包的依赖网络深度主要集中在 4-6 层。
传播比率：受前 20 个高频 CVE 影响的包中，有 13.9% 的包占据了整个网络覆盖的 50%。平均每个受影响包通过依赖链影响 3.6 个其他包（传播比率 3.6）。

4. 主要贡献 (Key Contributions)

大规模实证数据集：构建了包含超过 100 万个 npm 包及其依赖网络、1500+ 个唯一漏洞的关联数据库，填补了现有研究在数据规模和传递性依赖分析上的空白。
揭示“披露滞后”现象：首次大规模量化了 npm 生态中漏洞从“首次暴露”到“公开披露”的惊人滞后性（平均近 6 年），并指出大多数修复在披露前已完成。
量化传播集中度：证明了极少数的核心依赖包（Top 23 CVEs）是漏洞传播的“超级传播者”，修复这些少数漏洞可解决生态系统中一半以上的风险。
方法论创新：将生存分析应用于软件漏洞生命周期研究，更准确地处理了未修复（右截断）数据，提供了比算术平均更可靠的时间估算。

5. 意义与建议 (Significance & Recommendations)

对开发者的建议：
- 减少依赖：精简依赖树，移除未使用的库，防止开发依赖泄露到生产环境。
- 版本策略：采用宽松的版本约束（如 ^ 或 ~）而非硬编码版本，以便自动获取小版本和补丁更新。
- 主动监控：利用 npm audit 等工具，并关注 OSV/NVD 动态，但需警惕“最新即最安全”的误区（新包可能未经充分审计）。
对维护者的建议：
- 修复优先：在公开披露前完成修复（Pre-disclosure fixing），并明确标记修复版本。
- 工具改进：开发更智能的依赖分析工具，自动识别并建议更新到安全版本。
对生态系统的启示：
- 集中治理：由于漏洞高度集中在少数核心依赖中，安全资源应优先投入到这些高频 CVE 的修复和监控中。
- 范式转变：需要从被动响应转向主动防御，建立更快的披露 - 修复 - 采纳闭环。

6. 局限性 (Limitations)

静态分析局限：研究基于静态依赖树，可能高估了实际风险（因为某些漏洞代码可能未被执行）。
数据偏差：剔除了部分已弃用包，可能使结果偏向活跃库；OSV 与 NVD 的发布日期存在不一致性（平均 5 天差异，极端情况达 5 年）。
CVSS 版本：主要基于 CVSS v3.x，CVSS v4.0 的引入可能会改变部分严重性评分。

总结

该论文揭示了 npm 生态系统的一个“原罪”：虽然漏洞修复往往在公开披露前完成，但由于披露机制的严重滞后和下游用户补丁采纳的缓慢，加上高度集中的依赖网络结构，导致大量软件长期暴露在已知风险中。研究强调，解决这一问题不能仅靠增加漏洞发现速度，更需要优化披露流程、提升补丁采纳率，并针对核心依赖包进行重点治理。