SBOM：软件也应该有一份配料表

SBOM：软件也应该有一份配料表

买食品时，我们会看配料表；安装软件时，却很少知道它包含哪些第三方库。SBOM，也就是 Software Bill of Materials，软件物料清单，试图用机器可读的方式记录一个软件由哪些组件、版本和依赖组成。

SBOM 不只是一个依赖列表

简单的依赖文件通常告诉你“项目需要哪些包”。SBOM 还可以记录组件身份、版本、来源、许可证和关系。它关注的不只是直接依赖，还包括依赖的依赖，以及最终产物中实际包含了什么。

这让安全团队在某个组件爆出漏洞时，可以快速查询哪些产品受影响；也让许可证审查有了更明确的对象。SBOM 本身不负责修复漏洞，但能让“我们到底用了什么”从猜测变成清单。

为什么 AI 生成项目更需要它

AI 很擅长快速添加库和拼装示例，也容易在没有充分解释的情况下引入多个依赖。一个看起来只有几百行的 Vibe Coding 项目，可能依赖大量包、脚本和构建工具。没有清单，维护者很难知道哪些是必要组件，哪些只是模型为了实现一个小功能临时加入的。

SBOM 还可以帮助审查依赖漂移。若 AI 修改了包管理文件，清单 diff 能告诉你新增、删除和升级了什么，而不是只看一段自然语言总结。把这一步放进 CI，就能在合并前发现意外扩张的供应链。

SBOM 不能保证软件安全

一份完整的清单也可能包含有漏洞的组件，或者因为生成时机不对而漏掉运行时依赖。它还不能证明代码没有后门。SBOM 的价值在于提高可见性，后续仍需漏洞扫描、许可证审查、签名和构建来源验证。

普通开发者的最低实践

让 AI 添加新依赖时，要求它说明用途、维护状态和替代方案；提交前检查锁文件和依赖树；发布版本时生成一份 SBOM 并保留在构建产物旁边。哪怕项目很小，这也能在未来排查问题时节省大量时间。

SPDX 是常见的 SBOM 标准之一，具体介绍见 SPDX 官方页面。