从固件到应用：Mend.io实现SBOM全链路管理
欧盟《网络弹性法案》（Cyber Resilience Act, CRA）已正式将 SBOM（软件物料清单）列为强制性技术文档，要求覆盖产品全生命周期、具备准确性与可追溯性。对于同时涉及固件和上层应用的制造企业来说，"一份 SBOM 管到底"不再只是最佳实践，而是合规底线。
然而现实中，固件层和应用层的 SBOM 往往由不同团队、不同工具分别生成，格式不统一、更新不同步、漏洞关联断裂。本文从技术实践角度，拆解 SBOM 全链路统一管理的核心挑战，并分析 Mend.io 在其中的能力定位。
一、SBOM 全链路管理的核心挑战
1.1 数据源割裂
一个典型的 IoT 产品包含三层软件栈：
| 软件层级 | 典型组件 | SBOM 生成方式 |
|---|---|---|
| 固件层 | bootloader、内核、驱动、RTOS | 二进制逆向分析 / 固件解包扫描 |
| 系统层 | 操作系统、容器镜像、运行时库 | 包管理器解析 / 镜像分层扫描 |
| 应用层 | 业务代码、第三方库、框架 | 源码 SCA 扫描 / 依赖树解析 |
三层使用不同的技术路径和工具产出 SBOM，导致同一个产品可能存在三份相互独立的组件清单。当监管要求提交"完整的产品 SBOM"时，企业不得不手工拼合并去重，既耗时又容易遗漏。
1.2 格式与标准不统一
CRA 认可的 SBOM 标准格式包括 CycloneDX 和 SPDX。不同工具对标准的支持程度各异：
- CycloneDX v1.6 支持 VEX（漏洞可利用性交换）声明、AI 组件建模
- SPDX v3.0 引入了 AI、数据集、安全等专用 Profile
- 部分工具仅支持基础字段导出，缺少组件哈希、许可证、依赖关系等 CISA 要求的最小字段集
如果固件层工具输出 SPDX，应用层工具输出 CycloneDX，合并时需要做格式转换，转换过程中可能丢失扩展字段。
1.3 生命周期脱节
CRA 要求企业在产品上市后持续维护 SBOM 至少 5 年，并在新漏洞披露时评估影响范围。但许多企业的 SBOM 生成是"一次性"动作——仅在发布时生成一份快照，之后不再更新。当 Log4j 这类零日漏洞爆发时，企业无法快速回答"我的哪些产品受影响"。
二、Mend.io 的 SBOM 全链路能力
2.1 多层覆盖与统一格式
Mend.io 平台覆盖从源码到容器的完整技术栈：
- 源码层：Mend.io SCA 支持 200+ 编程语言和包管理器（npm、pip、Maven、NuGet、Go、Rust 等），自动解析直接依赖和传递依赖
- 容器层：Mend.io Container 分析容器镜像中的组件和漏洞，生成镜像级 SBOM
- 格式标准化：统一输出 CycloneDX 和 SPDX 双格式，支持源文件级细粒度导出
对于固件层，Mend.io SCA 本身不直接做二进制逆向分析。但 Mend.io 支持导入第三方 SBOM（含文件级组件），并触发异步匹配以识别源库和未匹配文件。这意味着固件层可以通过 ONEKEY 等专用工具生成 SBOM 后，导入 Mend.io 平台进行统一管理。
2.2 CI/CD 集成与自动化更新
Mend.io 提供三种扫描入口，覆盖开发全流程：
| 阶段 | 扫描方式 | 能力 |
|---|---|---|
| 编码阶段 | Mend.io IDE 插件 | 引入新依赖时即时检查漏洞和许可证 |
| 提交阶段 | 仓库集成（GitHub/GitLab/Bitbucket） | PR 提交自动触发扫描 |
| 构建阶段 | Mend.io CLI | CI/CD 管道中执行全面扫描（SCA + SAST + 容器） |
| 发布阶段 | 策略门禁 | 按预定义策略放行、告警或阻断构建 |
关键在于"持续监测"：即使代码未变更，当新漏洞被披露时，Mend.io 会重新评估已有项目的风险状态并通知安全团队。这直接满足 CRA 对"持续合规"的要求。
2.3 可达性分析与 VEX 声明
SBOM 的价值不在于"列出组件清单"，而在于"评估风险"。Mend.io 的可达性分析（Reachability Analysis）追踪应用代码到漏洞函数的完整调用路径：
- 如果漏洞函数从未被应用触达，标记为不可达，降低优先级
- 结合 CVSS 4.0 严重性评级和 EPSS 利用概率评分，创建风险调整后的待办列表
- 生成 VEX 声明，明确每个 CVE 在当前部署环境中的可利用性
VEX 声明可以减少 60%-80% 的 SCA 告警噪声。对于需要向监管提交合规证据的企业，VEX 是证明"已评估风险但无需修复"的关键文档。
2.4 SBOM 导入与聚合
2026 年 7 月的版本更新中，Mend.io 新增了源文件级 SBOM 导入功能：
- 支持导入包含文件级组件的 SBOM
- 导入后触发异步匹配，自动识别源库和未匹配文件
- 将外部 SBOM 与内部扫描结果聚合，形成统一的产品级 SBOM 视图
这意味着企业可以将固件层（ONEKEY 生成）、系统层（Syft 等工具生成）和应用层（Mend.io SCA 生成）的 SBOM 统一聚合到 Mend.io 平台管理。
三、与 CRA 合规要求的映射
| CRA 要求 | Mend.io 能力对应 |
|---|---|
| 提供产品 SBOM | SCA + Container 自动生成，支持 CycloneDX/SPDX 双格式 |
| SBOM 覆盖全生命周期 | CI/CD 集成 + 持续监测，新漏洞自动评估影响 |
| 漏洞与风险记录 | 可达性分析 + EPSS + VEX 声明 |
| 5 年生命周期管理 | 永久性违规追踪 + 零日漏洞目录 + 审计级记录 |
| 组件许可证合规 | 许可证策略管理 + 自动告警/阻断 |
四、实施建议
4.1 分层接入策略
对于同时有固件和应用的企业，建议采用分层接入：
- 应用层优先接入 Mend.io SCA，覆盖源码和容器镜像
- 固件层使用专用工具（如 ONEKEY）生成 SBOM，导入 Mend.io 平台聚合
- 系统层使用 Syft 等开源工具扫描容器镜像和 OS 包，导入 Mend.io 统一管理
4.2 自动化流水线设计
将 SBOM 生成嵌入 CI/CD 流水线，实现"构建即生成"：
- 每次 build 自动触发 SCA 扫描，生成版本化 SBOM
- SBOM 与制品版本绑定，支持按版本回溯
- 策略门禁阻断包含严重可达漏洞的版本进入生产
4.3 持续运营机制
- 配置零日漏洞响应工作流，新漏洞披露后自动评估影响范围
- 定期向监管提交 SBOM 更新和安全状态报告
- 建立内部 SBOM 审查流程，确保许可证和组件信息准确
Q&A
Q1：Mend.io 能直接扫描固件二进制文件吗？
Mend.io SCA 主要针对源码和包管理器生态。对于固件二进制，建议使用专用固件分析工具（如 ONEKEY）生成 SBOM 后导入 Mend.io 平台。Mend.io 支持导入第三方 SBOM 并做异步匹配和聚合管理。
Q2：CRA 要求的 SBOM 最小字段集是什么？
CISA 定义了 7 个最小字段：组件供应商、组件名称、版本、唯一标识符、依赖关系、SBOM 作者、生成时间戳。Mend.io 生成的 SBOM 包含这些字段，并额外提供组件哈希、许可证、CVE 上下文等扩展信息。
Q3：VEX 声明在 CRA 合规中的作用是什么？
VEX（Vulnerability Exploitability eXchange）用于声明某个 CVE 在特定产品环境中是否可利用。当 SBOM 中列出某组件存在已知漏洞，但该漏洞在当前部署中不可达时，VEX 声明可以作为"已评估但无需修复"的证据，减少不必要的补丁工作和监管沟通成本。
Q4：Mend.io 的 SBOM 是否支持多产品批量管理？
支持。Mend.io 平台支持组织级报告，可以在一个视图中查看所有产品的 SBOM 状态和漏洞情况。同时支持 API 导出，便于与企业的合规管理系统集成。
Q5：已经使用其他 SCA 工具，迁移到 Mend.io 的成本如何？
主要成本在于重新配置仓库集成和 CI/CD 管道。Mend.io CLI 支持主流包管理器，配置相对简单。历史 SBOM 数据建议以 CycloneDX/SPDX 格式导出后导入 Mend.io 平台，保留可追溯性。
Q6：SBOM 需要对外公开吗？CRA 有什么要求？
CRA 要求制造商在产品技术文档中维护 SBOM，并可在监管机构要求时提交。并非要求公开所有 SBOM 内容，但需要保证 SBOM 的完整性和可追溯性，支持漏洞响应和合规审计。