3. SBOM 核心要素：组件名称、版本号、供应商信息、许可证类型、依赖关系、漏洞信息
各位工程师朋友，咱们今天聊点实在的。SBOM 不是一张简单的物料清单，它是一份「数字身份证」。我做了这么多年工业设备，见过太多因为 SBOM 信息不全导致的翻车事故。说白了，SBOM 的核心就六个要素，缺一个都不行。
你想想看，一台数控机床里可能有上千个组件。每个组件叫什么、什么版本、谁造的、用什么许可证、依赖谁、有没有漏洞——这些信息必须清清楚楚。今天我就把这六个要素掰开揉碎了讲。
3.1 组件名称：别让命名毁了你的追溯
组件名称，听起来简单吧？但我告诉你，这里坑最多。我在项目中遇到过，同一个传感器，采购叫「SEN-1000」，研发叫「温度探头A」，仓库叫「TEMP-SENSOR-01」。结果一出问题，三个人说的不是一个东西。
我个人的习惯是：统一命名规范。工业设备里，组件名称必须包含三个部分：
- 功能描述：比如「温度传感器」「伺服驱动器」「PLC 模块」
- 型号标识：比如「TS-1000」「SVD-2048」「1756-L83E」
- 厂商缩写：比如「SIEMENS」「ABB」「OMRON」
命名示例：
- 正确：温度传感器_TS-1000_SIEMENS
- 错误：传感器1号（谁看得懂？）
嗯，这里要注意：组件名称不要用中文拼音缩写，不要用内部编号。你想想看，如果 SBOM 要交给客户或监管机构，人家看到「CGQ-001」这种名字，一脸懵。
3.2 版本号：精确到补丁级别
版本号是 SBOM 的灵魂。我见过最离谱的事——某设备用了 OpenSSL 1.0.1，但 SBOM 里只写了「OpenSSL 1.0」。结果 Heartbleed 漏洞爆发，查了半天才发现版本号写错了。
工业设备的版本号管理，我建议遵循 语义化版本规范：
| 版本段 | 含义 | 工业设备示例 |
|---|---|---|
| 主版本号 | 不兼容的 API 或功能变更 | V2.0.0 → 完全重新设计的控制逻辑 |
| 次版本号 | 向下兼容的功能新增 | V1.3.0 → 新增一个通信协议支持 |
| 补丁版本号 | 向下兼容的问题修复 | V1.2.5 → 修复了某个定时器溢出 bug |
我曾经踩过的坑：某次产线升级，供应商说「固件版本没变」，结果实际是编译时间不同，导致一个 Modbus 寄存器地址偏移了。从那以后，我要求版本号必须包含构建元数据（比如编译时间戳）。
版本号怎么写？我推荐这种格式：主版本.次版本.补丁版本+构建元数据。比如 2.1.3+20240315。这样谁都能一眼看出这是 2024 年 3 月 15 日编译的 2.1.3 版本。
3.3 供应商信息：不只是写个名字
供应商信息，很多人就写个「西门子」或「罗克韦尔」。这够吗？远远不够。工业设备出问题，你要能第一时间找到人。
我个人的做法是，供应商信息至少包含：
- 法定名称：比如「Siemens AG」而不是「西门子」
- 供应商 ID：比如 DUNS 编号或 CAGE 代码
- 联系点：技术支持邮箱或 URL
- 组件来源：是原厂、授权分销商还是二级供应商
小技巧：我习惯在 SBOM 里加一列「供应商可信等级」。A 级是经过审计的长期合作供应商，B 级是常规供应商，C 级是新引入的。这样风险评估时，一眼就能看出哪些组件需要重点审查。
3.4 许可证类型：工业设备也不能忽视
「工业设备又不开源，要许可证干嘛？」——这话我听过太多次了。但你想想，你的设备里有没有用 Linux？有没有用 OpenSSL？有没有用某个开源库？
工业设备里常见的许可证类型：
| 许可证类型 | 特点 | 工业设备注意事项 |
|---|---|---|
| GPL | 强 Copyleft，衍生代码必须开源 | 小心！如果你的控制软件链接了 GPL 库，整个固件可能被迫开源 |
| LGPL | 弱 Copyleft，动态链接可闭源 | 相对安全，但静态链接时要注意 |
| MIT / BSD | 宽松许可证，几乎无限制 | 工业设备首选，但别忘了保留版权声明 |
| Apache 2.0 | 宽松许可证，含专利授权 | 适合商业闭源产品 |
| 专有许可证 | 商业软件，需付费 | 注意授权范围和续费条款 |
我曾经翻过的车：某款设备用了 GPL 的库，但法务没审核 SBOM。结果客户要求查看源代码，我们不得不公开了部分核心算法。从那以后，许可证审查成了 SBOM 的必检项。
3.5 依赖关系：别让你的设备变成「蜘蛛网」
依赖关系是 SBOM 里最容易被忽略的要素。工业设备里，一个组件可能依赖十几个其他组件。比如一个简单的 Web 服务器，可能依赖 OpenSSL、libxml2、zlib、SQLite……
我习惯用 依赖树 来表示这种关系。直接依赖叫「一级依赖」，间接依赖叫「传递依赖」。你想想看，如果某个传递依赖有漏洞，你的设备照样不安全。
下面这张图是我常用的 SBOM 依赖关系结构：
你看，一个 Web 服务器依赖 zlib，zlib 又依赖 libcrypto。如果 libcrypto 有漏洞，你的 Web 服务器就不安全。这就是为什么依赖关系必须完整记录。
3.6 漏洞信息：SBOM 的最终价值
前面五个要素，最终都是为了第六个——漏洞管理。SBOM 的核心价值，就是让你能快速知道「我的设备有没有受某个漏洞影响」。
我建议在 SBOM 里记录以下漏洞信息：
- CVE 编号：通用漏洞披露编号，比如 CVE-2024-1234
- CVSS 评分：通用漏洞评分系统，0-10 分，越高越严重
- 影响版本范围：比如「OpenSSL 1.0.1 到 1.0.1f」
- 修复版本：比如「升级到 OpenSSL 1.0.1g」
- 状态：未修复、已修复、不适用、正在评估
实战建议：我每个季度都会跑一次 SBOM 漏洞扫描。工具不重要，重要的是流程。扫描结果出来后，按 CVSS 评分排序，先修 9 分以上的，再修 7 分以上的。工业设备不能随便停机，所以修复计划要跟维护窗口对齐。
嗯，这里有个细节要注意：漏洞信息不是静态的。今天没有漏洞，明天可能就爆出一个。所以 SBOM 要持续更新，不是做完就扔那不管了。
3.7 六个要素的关联关系
这六个要素不是孤立的。我画个简单的逻辑关系：
- 组件名称 + 版本号 → 唯一标识一个组件
- 供应商信息 → 告诉你找谁负责
- 许可证类型 → 告诉你法律风险
- 依赖关系 → 告诉你影响范围
- 漏洞信息 → 告诉你安全状态
说白了，前五个要素是「是什么」，第六个要素是「有什么风险」。没有前五个，第六个就是空中楼阁。没有第六个，前五个就是一堆数据，不是信息。
我的个人习惯：每次创建新设备的 SBOM，我都会先问自己三个问题：
- 这个组件叫什么？版本号是多少？（名称+版本）
- 谁造的？许可证允许我这么用吗？（供应商+许可证）
- 它依赖什么？有没有已知漏洞？（依赖+漏洞）
三个问题问完，SBOM 的核心要素就齐了。
好了，六个要素讲完了。记住，SBOM 不是写给别人看的，是写给自己用的。你记录得越详细，出问题时反应就越快。工业设备停一分钟损失多少钱？你自己算算。所以，别嫌麻烦，把每个要素都填完整。