技术摘要：揭示现实世界 Java 项目中隐藏的脆弱依赖项

问题陈述

现代软件开发高度依赖开源软件（OSS）组件，这些组件通常构成了项目代码库的大部分。虽然这加速了开发进程，但也引入了显著的安全风险，即引入了具有脆弱性的依赖项。现有的依赖扫描器通常分为两类：

1. 基于元数据的扫描器： 这些工具分析软件物料清单（SBOM），将声明的依赖版本与漏洞数据库（例如 CVE）进行匹配。它们速度快且具有可扩展性，但在依赖项被修改（例如被重新捆绑或重新打包）时会失效，因为此时元数据不再反映实际的代码内容。
2. 以代码为中心的扫描器： 这些工具通过分析实际的字节码来检测漏洞。虽然在应对修改方面非常有效，但它们极其消耗资源、运行缓慢，且通常需要特定的“修复提交”（fix commits）才能发挥作用，从而限制了其可扩展性。

Java 生态系统中存在一个关键的空白：开发者经常通过重新捆绑（将多个构件组合成一个 JAR 包）或重新打包（更改包名以避免冲突）来修改依赖项。这些修改改变了元数据和全限定名（FQNs），使得传统的基于元数据的扫描器对修改后的代码中存在的已知漏洞视而不见。

方法论：Unshade

作者提出了 Unshade，一种针对 Java 的混合依赖扫描方法，它结合了基于元数据的扫描的高效性和以代码为中心分析的检测能力。Unshade 分两个不同的阶段运行：

1. 导入阶段（知识库创建）

此阶段执行一次，用于构建已知脆弱构件的指纹数据库。

• 输入： 安全公告（例如 OSV 数据库），提供 CVE ID 以及相关的构件坐标（Group ID, Artifact ID, Version）。
• 过程：
  • Unshade 从公共仓库（如 Maven Central）检索相应的 JAR 文件。
  • 它从这些 JAR 文件中提取所有类。
  • 对于每个类，它计算两个哈希值：
    • 限定哈希（Qualified Hash）： 从原始字节码计算得出。这用于检测重新捆绑（即字节码保持不变的情况）。
    • 非限定哈希（Unqualified Hash）： 在执行“去限定化”步骤（即从字节码中剥离所有包相关信息）后计算得出。这用于检测重新打包（即包名被更改，导致 FQN 改变，但保留了结构逻辑的情况）。
• 输出： 一个存储了指纹（限定哈希集和非限定哈希集）并将其与特定构件及其关联漏洞相链接的知识库。

2. 扫描阶段（项目分析）

此阶段分析特定的 Java 项目，以识别隐藏的脆弱依赖。

• 输入： 为目标项目生成的 SBOM（例如 CycloneDX 或 SPDX）。
• 过程：
  • Unshade 检索该项目 SBOM 中列出的所有依赖项的 JAR 文件。
  • 它为项目依赖中的类计算相同的限定哈希和非限定哈希。
  • 匹配： 它检查项目哈希集与知识库指纹之间的子集关系：
    • 如果项目的限定哈希包含已知脆弱构件限定哈希的一个子集，则检测到重新捆绑的包含情况。
    • 如果项目的非限定哈希包含已知脆弱构件非限定哈希的一个子集，则检测到重新打包的包含情况。
• 输出： 一个增强型 SBOM，其中包含了原始声明的依赖项以及任何新识别出的隐藏（已修改）的脆弱依赖项。随后，该增强型 SBOM 会被传递给标准的基于元数据的扫描器（例如 Google 的 OSV Scanner）以报告最终的 CVE 列表。

核心贡献

1. Unshade 工具： 一种混合依赖扫描方法，通过字节码指纹技术增强 SBOM，从而识别被修改的脆弱依赖，有效地弥合了元数据分析与以代码为中心分析之间的鸿沟。
2. 大规模实证研究： 对 GitHub 上 1,808 个最流行的开源 Java Maven 项目（拥有 >500 个 Star 的项目）进行了全面的分析。
3. 开源实现： 作者提供了 Unshade 的公开实现，以促进进一步的研究和应用。

结果

研究得出了以下关于隐藏漏洞普遍性的发现：

• 修改的普遍性： 在分析的 1,808 个项目中，近 50%（899/1,808）的项目包含至少一个修改过的、已知具有脆弱性的依赖项，而该依赖项并未出现在原始 SBOM 中。
• 隐藏依赖的数量： 在这些项目中，Unshade 识别出了 7,680 个独特的修改后依赖项包含情况（按构件分组）。在这些受影响的项目中，平均每个项目包含了超过八个此类隐藏依赖。
• 修改类型： 在所有独特的包含情况中，76.1% 是重新捆绑的构件，23.9% 是重新打包的构件。
• 漏洞检测： 通过增强 SBOM，Unshade 使得检测到 7,712 个独特的 CVE 成为可能，如果仅依赖原始的基于元数据的 SBOM 和扫描器，这些漏洞将无法被检测到。
• 常见目标： 最常被重新捆绑的构件包括 netty-codec-http、tomcat-coyote 和 commons-lang3 等库。

性能开销

将 Unshade 集成到标准的漏洞扫描工作流中会引入适度的开销：

• SBOM 生成： 平均约 18.2 秒。
• Unshade 分析： 每个项目平均约 16.4 秒。
• 元数据扫描： 平均约 3.2–3.6 秒。
  作者指出，总耗时明显低于采用完整的以代码为中心的扫描器，这使得该方法对于大规模应用是切实可行的。

重要性与主张

论文声称，修改过的脆弱依赖项在现实世界的 Java 项目中是一个广泛存在且难以检测的威胁。传统的 SBOM 生成器（如 CycloneDX）和基于元数据的扫描器会系统性地遗漏这些包含情况，因为它们依赖于在重新捆绑或重新打包过程中被改变了的声明元数据。

Unshade 的重要性在于其能够：

1. 揭示隐藏风险： 它揭示了标准工具会忽略的修改后依赖项中的漏洞，从而提供更准确的安全态势。
2. 保持可扩展性： 通过使用指纹机制而非对每次扫描都进行深度代码分析，它保持了足够高效的规模化处理能力。
3. 增强现有工具： 它并非取代现有的扫描器，而是通过增强其输入（即 SBOM），使组织能够在利用现有元数据工具的同时，缓解其盲点。

作者总结道，虽然本研究侧重于根据 OSV 公告已知具有脆弱性的依赖项，但修改行为的普遍性表明，实际的安全风险可能更高，因为许多被修改的依赖项可能尚未在公共公告中被标记。