[Paper] 揭露真实世界 Java 项目中易受漏洞影响的依赖的隐藏包含

Source: arXiv - 2601.23020v1

概述

本文介绍了 Unshade，一种针对 Java 项目的混合依赖扫描技术，能够发现“隐藏”的易受攻击库——这些库已被重新打包、重命名或以其他方式修改，以致传统的基于元数据的扫描器无法检测到。通过将快速的 SBOM（软件材料清单）分析与轻量级的字节码指纹识别步骤相结合，作者揭示了流行开源 Java 项目中一个庞大且先前不可见的攻击面。

关键贡献

• 混合扫描流水线，在项目的 SBOM 中加入字节码级指纹，能够在不牺牲速度的前提下检测被修改的依赖。
• 基于字节码的指纹算法，即使库被重新打包、遮蔽或其他方式转换后仍能可靠识别。
• 大规模实证研究，对 GitHub 上 1,808 个高评分的 Maven 项目进行分析，显示约 50 % 的项目至少包含一个隐藏的易受攻击依赖。
• 量化影响：在隐藏的依赖中发现了 7,712 个不同的 CVE，受影响的项目平均每个包含超过 8 个隐藏的易受攻击库——这些都未被传统的元数据扫描器捕获。
• 开源原型（Unshade）已发布，展示了对真实代码库的实用可扩展性。

方法论

1. SBOM 生成 – 该工具首先使用现有元数据（groupId、artifactId、version）为目标 Maven 项目构建传统的 SBOM。
2. 字节码指纹 – 检查类路径上的每个 JAR；从公共类的字节码（方法签名、常量池条目等）生成确定性哈希。该指纹对重命名、遮蔽或重新打包具有鲁棒性。
3. 增强 – 将原始 SBOM 与指纹匹配已知开源组件但未在 Maven 元数据中列出的额外库进行合并，丰富 SBOM 内容。
4. 漏洞查询 – 将增强后的 SBOM 输入标准的基于元数据的漏洞数据库（例如 NVD、OSS Index）。由于隐藏的库已被表示，其对应的 CVE 将被检出。
5. 可扩展性验证 – 整个流水线每个项目仅需几秒钟即可完成，使其适用于 CI/CD 集成。

结果与发现

• 隐藏的易受攻击依赖 在 49.9 % 的研究项目中出现。
• 受影响的项目每个包含 平均 8.3 个隐藏的易受攻击库（范围 1–42）。
• 7,712 个唯一 CVE 仅在隐藏依赖中被发现；使用仅元数据工具扫描同一项目时，仅显示约 2,300 个 CVE。
• 与纯元数据扫描相比，指纹识别步骤仅增加了 < 2 % 的开销，证实了该方法在持续集成流水线中的实用性。

实际影响

• CI/CD 集成 – 团队可以将 Unshade 插入构建流水线，在发布前捕获隐藏的漏洞，补充现有的 SCA 工具。
• 风险管理 – 仅依赖声明的依赖项的安全仪表板会大幅低估风险；Unshade 提供更真实的暴露度指标。
• 供应链加固 – 采用“shaded”或重新打包库（在微服务框架中常见）的组织现在可以验证底层组件是否仍然安全。
• 策略执行 – 企业可以定义策略，阻止包含任何隐藏漏洞依赖的构建，从而降低意外暴露的可能性。
• 开发者认知 – 通过展示具体的隐藏库及其关联的 CVE，开发者获得可操作的洞察（例如，用最新的上游制品替换已 shading 的版本）。

限制与未来工作

• 语言范围 – 当前实现针对 Java 字节码；将指纹技术扩展到其他 JVM 语言（Kotlin、Scala）或生态系统（JavaScript、Python）仍是一个待解决的问题。
• 指纹冲突 – 虽然罕见，但理论上哈希可能与不相关的库冲突；作者建议添加更多字节码特征以提升唯一性。
• 漏洞数据库依赖 – 准确性取决于外部 CVE 数据源的完整性；缺失的条目仍将不可见。
• 动态加载 – 通过反射或自定义类加载器在运行时加载的依赖可能逃避静态字节码分析；未来工作可以加入运行时插桩。

Unshade 展示了对现有 SBOM 工作流进行适度的字节码层面微调，就能显著提升 Java 项目的安全可视性——这有力提醒我们，“看不见的东西”可能是软件供应链中最危险的环节。

作者

• Stefan Schott
• Serena Elisa Ponta
• Wolfram Fischer
• Jonas Klauke
• Eric Bodden

论文信息

• arXiv ID: 2601.23020v1
• 类别: cs.SE, cs.CR
• 发表时间: 2026年1月30日
• PDF: 下载 PDF