ARTICLE · 1042046
SBOM工具的盲区:软件供应链漏洞传播四阶段模型解析
SBOM工具的盲区:软件供应链漏洞传播四阶段模型解析> 文献来源：Propagation Model for SSC attacks: Why SBOM (tools) don’t tell the whole truth，arXiv预印本2609.05380v1 > 研究机构背景：列支敦士登大学（University of Liechtenstein），该校数据与应用安全研究团队长期从事网络威胁实证分析、软件供应链安全、威胁传播机理相关研究，聚焦真实攻击事件的技术复盘、现有安全工具能力边界评估，探索从漏洞发现到风险传导全链路的分析框架，产出多篇面向产业落地的供应链安全实证研究成果。 SBOM（软件物料清单）被业界和多国监管视作软件供应链安全的基础基础设施，在Log4Shell、SolarWinds等重大供应链攻击之后，NIS2、欧盟网络韧性法案CRA都在推动SBOM的强制落地。但现实中，完整的SBOM并不能等价于真实风险可控。列支敦士登大学的研究团队以Log4Shell（CVE‑2021‑44228）作为测试样本，提出**漏洞四阶段传播模型**，实证揭示主流开源SBOM工具只能完成前两个阶段的检测，无法判断代码可达性、污点数据流，由此带来大量误报，无法评估漏洞真实可利用性。文章区分了结构性传播和动态传播两类漏洞扩散行为，指出当前SBOM仅能提供组件资产清单，缺少对漏洞利用链路的分析能力，难以阻止普通网络风险演变为系统性生态风险。 NotPetya、SolarWinds、Log4Shell这三起标志性供应链攻击，共同的攻击逻辑都不是直接打击目标企业，而是利用上游依赖库、更新通道、第三方组件作为突破口，借助软件依赖信任关系实现风险大范围扩散。漏洞不再局限于单个应用内部，会顺着依赖链发生**传播效应**：一个组件的漏洞，传递给所有直接、间接依赖它的下游软件，形成级联影响。以Log4Shell为例，漏洞披露多年之后，仍然有大量 vulnerable版本的Log4j组件被下载，漏洞利用行为持续活跃，风险没有随着补丁发布而彻底消失。 行业普遍寄希望SBOM解决这类问题。SBOM可以枚举软件内部所有组件、版本、依赖关系，配合SCA软件成分分析，匹配公开CVE漏洞库，快速识别系统中存在哪些带漏洞的第三方库。按照理想预期，只要产出完整SBOM，就能快速定位受影响组件，完成处置。 但Log4Shell事件暴露出显著现实矛盾：很多企业已经拥有完整SBOM，扫描工具标记出高危CVE，却无法区分两种完全不同场景： 两类场景，SBOM扫描输出完全一致，统一标记为**CRITICAL高危漏洞**，产生极高误报率。根源在于：SBOM本质是一份静态资产清单，回答“我的软件里面装了什么组件”，但回答不了“这个组件的漏洞，在我的业务代码里面能不能真正触发”。 论文把供应链漏洞传播划分为两类，二者可以同时发生： 1. **结构性传播（依赖链传播）**：漏洞组件作为依赖，被下游软件继承。只要项目直接或者间接引入漏洞库，就发生结构性传播，只看依赖关系，和代码执行逻辑无关。例如Maven项目引入log4j‑core:2.14.1，无论写没写调用代码，都已经完成结构性传播。这是SBOM当前做得最好的部分。 2. **动态传播（利用级联效应）**：漏洞真正具备可利用条件，攻击者输入能够抵达脆弱代码，实现攻击横向移动、连锁破坏。动态传播取决于代码调用图、数据流，这是现有SBOM生态普遍缺失的能力。 研究团队基于Log4j漏洞完整利用链路，构建四阶段传播模型，漏洞从“组件存在”到“可以被外部攻击者利用”需要逐级走完这四个阶段，**每后一个阶段都建立在前一阶段满足的基础之上，阶段越高代表真实风险越大**。 > 核心判定：软件包中存在漏洞组件，可以是直接依赖，也可以是传递依赖，攻击面只是客观存在，尚未激活。 以Log4Shell案例，就是软件打包中包含log4j‑core 2.14.1版本。只确认组件版本是否存在，不去关心内部类有没有被删除、代码会不会被调用。 **工具实测表现**：Syft、Trivy、cdxgen这类SBOM生成工具在输入信息完整的前提下，大多可以识别到该组件。但识别结果高度依赖数据源，如果只扫描成品Jar包、缺少构建元数据，部分工具会发生漏检。 > 案例：Apache Solr 8.11.0、Spring Boot2.5.0、Ghidra10.0.4三个被测项目，都满足阶段1条件，SBOM工具能够检出log4j‑core组件。 > 局限：阶段1成立≠会被攻击，仅仅说明“炸弹已经放进仓库”，但引线不一定接上。 > 核心判定：漏洞对应的具体Java类文件物理存在于Jar包内，没有被裁剪、移除。对于Log4Shell，即`JndiLookup.class`文件真实存在。 很多场景下，上游组件虽然版本号是漏洞版本，但经过二次加工、裁剪，直接删除掉漏洞对应的class文件，此时即便版本号匹配CVE，实际不存在漏洞类。普通SBOM输出只描述组件包级别信息，默认不会枚举Jar内部每一个class文件，因此很难可靠完成阶段2校验。 **工具实测表现**：主流SBOM工具默认输出不能作为阶段2可靠证据，只有开启深度Jar解析模式时，少数工具可以输出类级别信息；多数情况下需要直接解压Jar包人工检查class文件是否存在。本次实验三个被测项目Jar包内都存在JndiLookup.class，阶段2全部成立。 > 局限：类文件存在，也不等于业务代码会调用这个类，相当于炸弹完整存在，但还没有电路接通。 > 核心判定：从应用业务代码的调用图，存在一条可执行路径，可以抵达漏洞方法。Log4Shell场景即业务执行路径可以调用到`JndiLookup.lookup()`脆弱方法。 这里需要构建程序调用图，理解方法调用、继承、接口、反射、框架动态行为，已经不属于资产清点，属于静态程序分析范畴。SBOM工具只做清单采集，不做调用图分析。哪怕Jar包里有漏洞类，如果业务代码完全没有任何路径可以走到该方法，漏洞就无法触发。 **工具实测表现**：Syft、Trivy、Grype、cdxgen全部无法完成阶段3检测。即便SBOM报告标记高危CVE，也不能证明代码可达。研究人员使用CodeQL对三个被测项目做源码分析，结果显示：**三个项目源码中，均没有直接调用JndiLookup相关方法，没有源码层面引用该类**。 > 案例解读：Ghidra、Spring Boot样例项目虽然打包带漏洞Log4j库，Jar包里有JndiLookup类，但应用代码没有调用路径走到该漏洞方法，阶段3不成立。这就解释大量SCA误报：组件版本匹配CVE，但业务根本跑不到脆弱代码。 > 关键结论：阶段3是重要分水岭，**阶段2到阶段3之间的鸿沟，就是当今SBOM/SCA工具高误报的根本来源**。 > 核心判定：攻击者可控外部输入（HTTP请求头、URL参数、表单、请求体等污点源）能够流入日志打印接口（sink汇点）。Log4Shell要完成远程代码执行，不仅脆弱代码要可达，还必须有攻击者可控字符串交给Log4j输出打印。 即便阶段3达成，脆弱方法可以被调用，如果所有传给日志的字符串都是程序内部固定常量，没有任何外部可控输入，攻击者依然无法注入JNDI恶意表达式，漏洞依旧不可利用。阶段4需要污点传播分析能力，追踪数据从外部输入到日志函数的数据流。SBOM完全不具备数据流分析能力。 **工具实测表现**：SBOM工具全部无法覆盖阶段4。实验中采用Semgrep污点分析规则做检测，得到不同结果： > 也就是说：同样标记Log4Shell高危CVE的三个项目，只有Apache Solr存在潜在完整利用链路，另外两个即便存在漏洞组件，缺少攻击者可控输入，实际很难被外部利用。SBOM输出却把三者同等标记为最高危险等级。 研究选取四款行业广泛使用开源SBOM工具：Syft（SBOM生成）、Trivy（一体化扫描+SBOM）、Grype（漏洞扫描，读取Syft产出SBOM）、cdxgen（构建时CycloneDX SBOM生成），结合CodeQL、Semgrep程序分析工具开展对比实验，得到核心结论： 论文同时验证两条预设假设： 该研究指出，阶段2与阶段3之间是当前供应链安全工具最关键缺口。未来SBOM工具演进，不应该只追求把组件清单做的更完整，更需要探索如何把调用图、可达性、污点路径等分析结果标准化，附加到SBOM输出中。模型本身也可以进一步扩展，纳入更多攻击场景，不只局限Log4j这类库漏洞，推广到更多软件供应链攻击类型。
# SBOM工具的盲区：软件供应链漏洞传播四阶段模型解析
https://arxiv.org/pdf/2609.05380
## 摘要
## 一、背景：供应链攻击与SBOM的现实困境
应用接收HTTP用户输入，输入内容会交给Log4j打印日志，真实可被攻击者远程利用； 应用虽然打包了存在漏洞的Log4j库，但只打印内部调试常量字符串，不存在外部可控输入流入日志接口，实际无法被攻击。
### 两个关键传播定义
## 二、漏洞四阶段传播模型（以Log4Shell案例说明）
### 阶段1：结构性暴露（Structural Exposure）
### 阶段2：漏洞类存在（Vulnerable Class Presence）
### 阶段3：代码可达性（Code Reachability）
### 阶段4：污点路径确认（Taint Path Confirmation）
Apache Solr 8.11.0：检测到候选污点路径，HTTP授权请求头getHeader("Authorization")流入log.debug()日志打印，属于攻击者可控输入流向日志接口，阶段4具备候选条件。在满足日志级别开启、JndiLookup可用等附加条件后，就存在真实攻击风险。 Ghidra10.0.4：识别到变量流入日志，但变量来源是本地文件路径，不属于远程攻击者可控输入，不构成完整利用链。 Spring Boot 2.5.0测试样例：所有日志打印全部是硬编码常量字符串，完全没有外部输入流入，没有候选污点路径。
## 三、实验结论：现有SBOM工具能力边界
当前SBOM生态系统，系统地只支持模型的阶段1和阶段2。可以很好回答“软件里面装了什么带漏洞组件”，部分场景能识别Jar内部类是否存在。 阶段3代码可达性、阶段4污点路径分析，是现有SBOM工具完全缺失的能力。SBOM只是清单，不构建调用图、不追踪数据流，因此无法评估漏洞动态传播与真实可利用性。 这直接解释SCA扫描普遍90%以上的高误报现象：版本匹配CVE就告警，不区分代码是否可达、有没有攻击者可控输入。 技术上阶段3、4是可以实现的，需要引入程序静态分析、污点分析工具（CodeQL、Semgrep等），但这不属于传统SBOM的能力域。SBOM可以作为输入数据源，但不能独立完成风险评估。
假设1成立：SBOM工具不能区分“存在攻击者输入”和“仅打印内部常量”两类应用，两者输出完全一样的高危CVE告警，不管脆弱方法会不会被调用。 假设2成立：被测开源SBOM工具都无法检测动态传播效应，不能评估漏洞被利用之后能否横向移动、造成级联破坏。
## 四、对软件供应链安全实践的启示
不要将SBOM扫描告警直接等同于真实业务风险。SBOM解决“看得见有什么组件”，不等于“评估风险能不能被利用”。运维安全团队不能看到SBOM输出高危CVE就一刀切紧急升级，要做二次可达性、数据流研判，否则会带来巨大的改造成本。Log4j事件中大量企业就是受困于此，项目依赖链复杂，升级牵一发动全身，但很多应用实际不存在可利用链路。 软件供应链风险评估需要分层：先做SBOM资产清点（阶段1‑2），再叠加代码可达性分析（阶段3），再做污点数据流分析（阶段4），多层结合才可以完成漏洞真实可利用性研判。SBOM是基础输入，而不是完整解决方案。 监管层面推行SBOM的同时，不能只要求产出物料清单，未来工具演进需要考虑补充可达性、污点分析相关元数据，把传播阶段信息融入SBOM扩展字段，区分“组件存在漏洞”和“漏洞可被外部利用”。 漏洞风险会从个体软件风险演变为生态系统性风险，根源就是漏洞顺着依赖链结构性传播，又在部分下游软件中满足动态利用条件。只靠资产清单，无法阻断这种级联风险。