💻 computer science

Hidden Amplifiers: Cross-Level Risk in Software Supply Chains

本文引入了一种跨层级风险传播框架，该框架通过桥接生态系统级依赖图与代码级静态分析，旨在识别出当前软件成分分析（SCA）工具所遗漏的“隐蔽放大器”——即具有高生态暴露度但低代码复杂度的微观依赖，从而揭示软件供应链安全中的关键盲点。

原作者： Rakesh Podder, Rafael Fabian Gonzalez Arellano, Indrajit Ray

发布于 2026-07-08

📖 1 分钟阅读☕ 轻松阅读

原作者： Rakesh Podder, Rafael Fabian Gonzalez Arellano, Indrajit Ray

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

想象一下，你是这座繁忙、庞大城市的安保主管。这座城市完全由预制模块（软件包）建成，而开发者可以从一个巨大的市场（软件供应链）中购买这些模块。

目前，这座城市有两个独立的安保团队，但他们彼此并不沟通。本文认为，这种分离正在制造危险的盲点。

两个安保团队（问题所在）

“代码侦探”团队： 这些人负责检查单栋建筑内部。他们检查布线是否混乱、门是否脆弱或蓝图是否令人困惑。他们非常擅长发现特定建筑内部的结构性缺陷，但他们不知道城市中还有多少其他建筑依赖于此。
“人口统计”团队： 这些人站在外面，统计有多少人依赖于某栋建筑。他们知道 A 栋建筑被 100 万人使用，而 B 栋建筑仅有 10 人使用。他们知道哪些建筑是“关键”的，但他们从未进入建筑内部去检查布线是否安全。

失败之处：

代码侦探可能会大喊：“这栋建筑有一扇破窗户！”但如果只有一个人使用它，这并不是什么大事。城市会被大量的虚假警报所淹没。
人口统计员可能会说：“C 栋建筑被所有人使用！”但如果他们从未进去查看，他们就会错过 C 栋建筑实际上只是一个极其简单、甚至连窗户都没有的小棚屋这一事实。或者更糟的是，他们会忽略一个极其简单的棚屋中存在的微小隐藏缺陷，而这个棚屋正是所有人都在依赖的。

“隐藏放大器”（发现）

研究人员发现了一种新型危险，他们称之为**“隐藏放大器”**。

想象一下，城市中心一个不起眼的电线杆。它看起来非常简单——可能只有几根电线和一个小盒子（很少的代码行）。标准的代码侦探会观察它并说：“这太简单了，不会有危险。”

然而，这个特定的电线杆是另外 5 万栋建筑的主要电源。如果这个微小的电线杆失效，或者黑客修改了一根电线，5-万栋建筑都会陷入黑暗。

现有工具对此视而不见： 因为这个电线杆太简单了，代码工具会忽略它。因为该电线杆还没有已知的“犯罪记录”（漏洞），人口统计工具也会忽略它。
结果： 这些微小且关键的组件可以就此静静地坐落在那里，等待被利用，对所有人来说都是隐形的。研究人员在测试的 50 个软件包中，竟然发现了 12 个这样的“隐藏放大器”。其中一个例子是一个名为 ms 的微型包（仅有 5 个方法），它被近 83 万个其他项目所使用。

新方案：“跨层级”地图

作者构建了一个新的框架，强制要求这两个安保团队协同工作。他们创建了一个单一的“风险评分”，结合了以下两点：

代码内部的复杂度和重要程度（侦探的视角）。
有多少人依赖它（统计员的视角）。

用通俗语言解释公式：

总风险 = （代码有多乱/多重要） × （有多少人在关注它）

如果一段代码既混乱又被广泛使用，其风险评分就会爆炸式增长。如果它很混乱但无人使用，风险就很低。如果它被数百万人使用但非常简单，风险仍然是可控的。但如果它是一个被数百万人依赖的微小、简单的代码片段，新系统就会将其标记为“隐藏放大器”，需要立即关注。

研究结果

研究人员在 50 个流行的软件包（例如用于构建网站和应用程序的包）上测试了这一方法。

他们找到了“隐藏放大器”： 他们识别出了 12 个微型包，这些包被数以万计的其他项目使用，但在目前的安全工具面前却处于监管盲区。
更好的优先级排序： 当他们使用这种新方法对最危险的代码进行排名时，他们发现，相比于仅看流行度或仅看代码复杂度，这种方法能更好地发现真实威胁。它能帮助开发者确定应该先修复哪些具体的代码行。
现实世界测试： 他们回顾了 ms 包在 2017 年发生的一次著名漏洞。当时，没有任何工具将其标记为危险，因为它太简单了，且没有之前的“犯罪记录”。但如果当时使用了他们的新系统，由于其巨大的覆盖范围，ms 会被列为最高优先级，从而可能在黑客攻击发生前向开发者发出警告。

底线结论

论文得出结论，我们不能只孤立地看待代码，也不能只看一个包的流行程度。我们需要同时观察这两者。通过这样做，我们可以找到软件供应链中那些目前对我们的安全工具而言是“隐形”的、微小但关键的部分，从而在灾难发生前防止其发生。

他们构建了一个原型工具（约 16,000 行代码）来实现这一点，证明了弥合“代码质量”与“生态系统覆盖范围”之间鸿沟的可能性。

技术摘要：软件供应链中的隐藏放大器与跨层级风险

问题陈述
现代软件供应链依赖于数百个传递依赖，然而目前的分析工具在运行层面是孤立的：生态系统级工具（如 Snyk、Dependabot）在不检查代码的情况下分析依赖图；而代码级工具（如静态分析器）在不考虑生态系统上下文的情况下检查包的内部实现。这种分离导致了两种关键的失效模式：

误报过载： SCA 工具会对消费型应用程序从未执行的代码路径中的漏洞发出警报，导致开发者忽略警报并掩埋了真实的威胁。
隐藏放大器盲点： 具有微小代码结构但拥有巨大生态系统影响力的微依赖（例如 ms，拥有 829,000 个依赖方）承载了过度的结构性风险。由于它们缺乏先前的 CVE 记录且代码简单，因此在 SCA 和代码质量工具中都是不可见的。

方法论：跨层级风险框架
作者提出了一个通过统一风险公式将代码级指标与生态系统级暴露度相连接的框架。该方法由三个层级组成：

生态系统分析（第 1 层）： 计算包 $p$ 的生态系统暴露度 ( $\psi$ )，其定义为通过 deps.dev 获取的入度（传递逆依赖计数）。该层还通过健康指标（OpenSSF Scorecard、libyears）和已知 CVE 来丰富依赖图，以提供分选上下文。
代码分析（第 2 层）： 计算包内每个方法 $m$ $m$ 的代码级风险 ( $\phi$ $ϕ$ )。该指标由以下因素导出：
- 圈复杂度 ( $c$ )
- 包内调用图中的介数中心性 ( $b$ )
- 爆炸半径（传递可达的被调用者）( $r$ )
- 基于 Git 提交频率的时间变动因子 ( $\tau$ )。
- 置信度门槛： 系统计算内部解析率 ( $R$ ) 以量化调用图的完整性，将具有高动态分派特征的包（ $R < 0.85$ ）标记为置信度较低。
跨层级综合（第 3 层）： 使用乘法模型将两个维度结合成单一的跨层级风险 (CLR) 分数：
$CLR(m) = \phi(m) \cdot f(\psi(pkg(m)))$
其中 $f$ 是单调递减函数（默认： $\log_{10}(x+1)$ ），旨在防止高入度包完全主导排名，同时仍能放大其风险。

核心贡献

统一风险框架： 一个将方法级代码指标与生态系统级依赖暴露度相统一的数学模型，实现了不同包之间方法的直接比较。
多层级架构： 一个可分解的分析流水线，并通过一个支持 npm 和 PyPI 的 16,000 行开源原型进行了验证。
识别“隐藏放大器”： 该框架定义并检测出一类具有少于 50 个方法但拥有超过 50,000 个依赖方的微依赖。这些包在结构上至关重要，但在当前的软件成分分析 (SCA) 工具中是不可见的。

评估结果
作者在包含高影响力框架和微依赖在内的 50 个包（35 个 npm，15 个 PyPI）的语料库上评估了该原型。

隐藏放大器检测： 语料库中有 24%（12 个包）符合隐藏放大器的特征。对 ms 包（该包在 2017 年遭受 ReDoS 漏洞攻击）的回溯分析表明，该框架仅凭结构位置就会将其标记为高风险，而当时没有任何现有的 SCA 工具这样做。
优先级排序精度： 在针对 10 个已知 CVE 的根包进行的特性研究中，跨层级评分 (CLR) 和仅代码评分 (CR) 的表现显著优于仅入度评分 (FI)。具体而言，CLR 和 CR 的 Precision@K 大约是 FI 的两倍。
排名稳定性： 该框架实现了跨依赖项的排名能力，这是单层级工具所不具备的。虽然仅代码工具可以对包内的的方法进行排名，但只有 CLR 能够将一个低复杂度、高依赖包中的方法与一个利基包中的高复杂度方法进行对比排名。
可靠性： 在分析的包中，70% 的包实现了 $\geq 0.85$ 的内部解析率 ( $R$ )，表明静态分析具有较高的可靠性。系统透明地报告 $R$ 值，以便从业者评估置信度。

意义与主张
论文声称，当前代码质量工具与生态系统级 SCA 之间的分离是一种设计局限，而非内在边界。通过桥接这两个层面，所提出的框架：

为解决当前工具链盲点的供应链安全开辟了新的设计空间。
提供了一种在漏洞披露前识别结构性关键微依赖的机制。
证明了代码感知的排名相比仅基于生态系统的方案，能显著提高漏洞优先级排序的精度。

作者指出，目前的实现侧重于依赖内向的可达性，而完整的跨包调用图构建仍是未来的工作。评估被视为一次可行性演示，并承认所选取的语料库可能过度代表了维护良好的软件包。