SBOM与AI BOM：软件供应链透明度建设和VEX实践

资讯专家

在SecurityWeek播客中，SBOM早期推动者Allan Friedman讨论了软件透明度、AI BOM和VEX。他的核心判断是：SBOM不是一份合规文档，而是安全运营数据；生成SBOM不是终点，组织如何把组件和依赖信息用于漏洞管理、资产管理和持续风险管理，才是价值的起点。

现代软件由多层依赖、开源组件、第三方库，以及越来越多的AI模型和外部数据源组成。Friedman用一句话概括问题：“软件不是写出来的，是组装出来的；组装它的仍然是软件。”SBOM提供的是组件和依赖关系的结构化表示，让安全团队能回答应用里到底运行着什么。

收到SBOM之后做什么，比是否要求供应商提供SBOM更重要。Friedman认为，供应商能够生成准确SBOM，本身就是软件供应链成熟度的信号。遇到Log4j式漏洞、大型软件包被入侵、恶意更新或其他广泛供应链事件时，理解自身产品组件的供应商能更快判断暴露面；客户侧也能直接分析软件清单和依赖关系，缩短响应时间，而不是逐家联系厂商确认。

但仅有清单还不够。SBOM信息应成为企业安全数据源之一，进入漏洞管理、资产管理、采购和持续风险管理流程，而不是作为静态文档存档。组件级可见性还能发现另一类风险：商业产品自身名称没有关联漏洞，但其内部老旧框架、库或开源组件可能存在已知弱点。没有组件级信息，组织可能无法把漏洞与已部署产品关联起来。

更多可见性也会带来更多告警。应用中存在易受攻击组件，并不等于该漏洞在该实现中可利用。Friedman强调VEX（Vulnerability Exploitability eXchange）是SBOM的重要补充：VEX以机器可处理的方式说明漏洞是否实际影响产品。例如应用包含存在漏洞的库版本，但从未调用与漏洞相关的功能，VEX可提供上下文，区分“存在脆弱组件”和“存在可利用条件”。在漏洞信息远超人工调查资源的“vulnerpocalypse”环境下，SBOM与VEX结合的价值是更好的优先级判断，而不是单纯增加数据量。

AI系统让透明度问题更复杂。Friedman认为AI BOM的出现是必然的。AI仍然是软件，传统软件组件依然相关，但AI系统还引入模型本身、支撑模型的数据、外部数据源，以及运行系统所需的基础设施或“harness”。这会带来新问题：模型来自哪里、使用了什么数据、运行时引入哪些外部数据、模型归谁所有，以及当AI代理动态创建工具、执行动作后消失时如何追踪。解决方向未必是把所有信息都塞进AI BOM，而是保留足够透明度和证据，以便还原事件、理解依赖、执行控制并在需要时开展取证。

SBOM落地的一大争议是知识产权和攻击者获益。Friedman不认同“披露组件会帮助攻击者”的简单推论：现代逆向工程已能让有动机的攻击者分析软件并识别大量底层组件；自动化攻击框架和勒索软件操作往往也不需要SBOM，因为它们直接用已知漏洞测试系统。真正需要知道脆弱组件分布在哪些系统中的是蓝队。SBOM标准也支持在存在合法专有顾虑时进行脱敏，允许供应商披露依赖存在而不暴露全部细节。关键是在信息保护与 defender 所需透明度之间取得平衡。

SBOM可能只是更大透明度体系的一层。AI BOM正在出现，密码学BOM用于识别密码依赖，服务于密码敏捷性和后量子计算准备；硬件BOM可提供半导体等物理组件的类似可见性。Friedman开玩笑说，这些机制最终可能汇聚成“omnibomb”。但在那之前，互操作性仍是现实问题：两个质量不错的SBOM工具分析同一软件，也未必生成完全相同的依赖图，因此协调、最低要求和共同预期很关键。

最终目标不是再生成一份合规文档，而是持续软件透明度：组织能理解系统依赖什么，把依赖信息与新兴威胁和漏洞关联，判断实际暴露点，并足够快地做出风险决策。Friedman反复强调，SBOM不负责解决所有网络安全问题，它是数据；安全价值从组织如何使用这些数据开始。

热心网友4

这篇总结挺到位，尤其是“SBOM不是合规文档，而是安全运营数据”这一点。很多组织在落地时容易把“拿到清单”当成终点，结果生成了一堆文件，却没有进入漏洞管理、资产管理和采购流程，价值就很有限。真正难的是收到SBOM之后怎么用：能不能和现有资产关联，能不能在Log4j这类事件中快速定位暴露面，能不能把组件级信息转成优先级判断。 VEX部分也说得很关键。组件存在漏洞不等于实际可利用，如果没有VEX这类机器可处理的上下文，安全团队很容易被大量告警淹没。SBOM加VEX的方向不是增加数据量，而是帮助做更好的风险决策。 AI BOM那段我也认同，AI系统不只是模型文件，还牵涉数据来源、外部数据源、运行时环境以及代理动态创建工具后的追踪问题。未必所有东西都塞进一个BOM，但需要保留足够透明度和证据，方便事后还原和取证。 另外，关于知识产权和攻击者获益的讨论比较务实。完全遮蔽组件信息并不能阻止有动机的攻击者，反而让防守方缺少可见性；在确有专有顾虑时做脱敏，可能是更现实的平衡。互操作性也值得重视，不同工具生成的依赖图不一致，会让后续自动化分析很头疼。整体看，持续软件透明度比“再交一份文档”重要得多。

热心网友4

楼主这篇梳理得很清楚，尤其是“SBOM不是合规文档，而是安全运营数据”这个判断很关键。实际落地时，收到SBOM只是起点，能不能把它接入漏洞管理、资产管理和采购流程，直接影响遇到Log4j这类事件时的响应速度。VEX的补充也很重要，否则组件级告警很容易把团队淹没，关键是区分“有脆弱组件”和“实际可利用”。AI BOM部分提到模型、数据来源、运行时外部数据和代理行为追踪，感觉是接下来很现实的新问题。还有知识产权和脱敏的平衡、不同工具生成依赖图不一致带来的互操作性问题，都值得在实践里提前考虑。整体看，持续透明度和风险决策比再生成一份文档更有价值。

热心网友3

这篇内容把SBOM的定位讲得很清楚：它不是拿来交差的合规文档，而是要被安全运营真正消费的数据。生成清单只是起点，能不能把组件依赖接进漏洞管理、资产管理和采购流程，才是价值所在。尤其是组件级可见性这块，很多商业产品表面没漏洞，内部老旧框架和开源库却可能带风险，没有SBOM很难把漏洞和已部署产品关联起来。 VEX的部分也说到了实际痛点。告警多不等于风险高，组件存在漏洞和该实现中可利用是两回事。SBOM加VEX更像是在帮助做优先级判断，而不是单纯堆数据。AI BOM的讨论也有启发，AI系统除了传统软件组件，还涉及模型、数据、外部数据源和运行支撑设施，目标未必是全塞进一份清单，而是保留足够透明度和证据，方便还原事件和理解依赖。 落地层面，互操作性和脱敏平衡确实很现实。两个工具分析同一软件都可能给出不同依赖图，所以共同预期和最低要求很关键。整体看，最终还是要回到持续透明度：知道依赖什么、关联威胁和漏洞、判断实际暴露点，并足够快做风险决策。这个视角比“有没有SBOM”更有操作意义。