摘要
现代嵌入式产品和 IoT 设备同时包含固件层与应用软件层，二者的安全治理长期处于割裂状态。本文分析固件安全与软件安全各自的技术特征与管理痛点，介绍以 Mend 为核心、ONEKEY 为固件补充的整合方案，并给出可落地的协作架构与适用场景。
一、业务背景：固件与软件安全为何需要统一管理
1.1 安全治理的现实割裂
在多数制造型企业和 IoT 产品团队中，固件安全与软件安全由不同团队、使用不同工具链分别管理：
- 固件侧：由嵌入式团队负责，关注二进制分析、硬件接口安全、引导链验证，工具多为逆向工程类或专用固件扫描器。
- 软件侧：由应用开发团队负责，关注开源组件漏洞（SCA）、代码质量（SAST）、依赖合规，工具以 Snyk、Mend、Checkmarx 等为代表。
两套工具链产出的数据格式不同、漏洞库不同、风险评级标准不同，导致安全团队在汇总产品级风险时，需要大量人工对齐。
1.2 CRA 法规带来的合规压力
欧盟《网络弹性法案》（Cyber Resilience Act, CRA）于 2024 年正式生效，要求所有在欧盟市场销售的含数字元素产品（包括固件和软件）满足以下义务：
- SBOM 生成与维护：产品交付时须提供结构化软件物料清单，覆盖固件层与应用层的全部组件。
- 漏洞持续监控：制造商须对产品全生命周期内的已知漏洞进行监控和响应。
- 安全更新机制：产品须具备可靠的远程更新能力，且更新过程本身须经安全验证。
ENISA 在 2025 年发布的《SBOM Implementation Guide》中明确指出：SBOM 的完整性取决于对"所有可执行层"的覆盖，仅覆盖应用层而忽略固件层的 SBOM 不满足 CRA 的合规要求。
1.3 统一管理的核心挑战
| 挑战维度 | 固件安全 | 软件安全 |
|---|---|---|
| 分析对象 | 二进制文件、ELF/PE 固件镜像 | 源代码、包管理器依赖 |
| 组件识别方式 | 字符串特征匹配、逆向工程 | 包管理器解析（package.json、pom.xml 等） |
| 漏洞关联 | CVE + 厂商私有公告 | CVE + NVD + 安全公告 |
| 更新机制 | OTA 固件升级（需硬件验证） | 依赖版本升级（自动化程度高） |
| 典型工具 | ONEKEY、Binwalk、Ghidra | Mend、Snyk、Dependabot |
割裂的管理模式导致三个核心问题：风险可见性不完整（无法看到跨层关联漏洞）、合规证据链断裂（固件和软件的 SBOM 无法合并为统一视图）、修复协调困难（固件更新周期远长于软件更新）。
二、产品能力解读：Mend + ONEKEY 如何协同
2.1 Mend：软件供应链安全的核心引擎
Mend（原 WhiteSource）是面向软件开发全生命周期的供应链安全平台，核心能力覆盖三个层面：
SCA（软件成分分析）
- 支持 30+ 种编程语言的依赖检测，包括 Java、Python、Go、Rust、C/C++ 等。
- 基于 Mend 自有的漏洞数据库（整合 NVD、供应商公告、安全研究团队独立发现），提供漏洞检测与严重性评级。
- 支持传递依赖分析，可识别间接引入的嵌套漏洞组件。
许可证合规管理
- 自动识别开源组件的许可证类型（GPL、MIT、Apache 等），检测许可证冲突。
- 对于面向欧盟市场的产品，许可证合规与 CRA 的 SBOM 义务构成双重保障。
自动化修复建议
- 针对检测到的漏洞组件，提供具体的版本升级建议和兼容性评估。
- 支持与主流 CI/CD 平台（Jenkins、GitHub Actions、GitLab CI）集成，实现"检测-告警-修复"闭环。
2.2 ONEKEY：固件与二进制安全的专用平台
ONEKEY 专注于固件和嵌入式系统的安全分析，其核心能力恰好覆盖 Mend 的分析盲区：
固件逆向与 SBOM 生成
- 支持从二进制固件镜像中提取组件信息，生成标准格式（CycloneDX、SPDX）的 SBOM。
- 覆盖多种嵌入式架构（ARM、MIPS、RISC-V、x86）和固件打包格式。
固件漏洞关联与风险评估
- 将提取的组件版本与 CVE 数据库关联，结合固件运行环境评估漏洞的实际可利用性。
- 识别固件特有的安全问题：硬编码凭据、不安全的引导配置、未加密的通信通道等。
合规审计引擎
- Compliance Wizard 功能提供向导式合规评估，覆盖 CRA、IEC 62443、ETSI EN 303 645 等标准。
- 自动生成面向审计方的合规差距报告。
2.3 整合架构：协同工作流
两个产品的整合不是简单的功能叠加，而是构建一条从源代码到固件镜像的完整安全链条：
undefined
源代码层（Mend 覆盖）
↓ SCA 检测 → 生成源码层 SBOM（CycloneDX/SPDX）
↓ 许可证合规检查
↓ 漏洞修复建议 → 开发团队执行升级
构建阶段
↓ 编译打包 → 生成固件镜像
固件层（ONEKEY 覆盖）
↓ 二进制分析 → 生成固件层 SBOM
↓ 固件特有安全检测
统一输出
↓ SBOM 合并 → 产品级完整 SBOM
↓ 统一漏洞视图 → 跨层风险关联
↓ 合规报告生成 → CRA / IEC 62443 审计整合的关键衔接点在于 SBOM 的格式统一：Mend 输出的源码层 SBOM 与 ONEKEY 输出的固件层 SBOM 均采用 CycloneDX 或 SPDX 标准格式，使得两层数据可以在下游合并为产品级 SBOM。
三、适用场景与落地建议
3.1 哪些企业适合这套整合方案
| 企业类型 | 适用度 | 关键理由 |
|---|---|---|
| IoT / 智能硬件制造商 | 高 | 产品同时含固件和云端应用，CRA 合规要求双层覆盖 |
| 工业设备厂商（IEC 62443） | 高 | 工控固件安全 + 上位机软件安全需统一管理 |
| 汽车电子（Tier 1/Tier 2） | 中高 | 固件安全为刚需，车机软件层同样需要 SCA |
| 纯软件 SaaS 企业 | 低 | 无固件层，Mend 单独即可满足需求 |
| 纯硬件（无联网） | 低 | 不在 CRA 覆盖范围内 |
3.2 推荐的落地步骤
阶段一：评估与试点（2-4 周）
- 梳理产品线中涉及固件 + 软件组合的设备清单。
- 选取 1-2 个代表性产品，分别用 Mend 扫描源码、用 ONEKEY 分析固件。
- 验证两层 SBOM 的格式兼容性和数据完整性。
阶段二：流程整合（4-8 周）
- 将 Mend 集成到现有 CI/CD 流水线，实现源码层的持续扫描。
- 在固件发布流程中增加 ONEKEY 分析节点，每次固件构建后自动生成 SBOM。
- 建立 SBOM 合并与统一漏洞视图的工作流。
阶段三：持续运营
- 建立跨团队的漏洞响应机制：固件团队和软件团队共享统一漏洞看板。
- 定期输出产品级合规报告，满足 CRA 的持续监控义务。
- 利用 Mend 的自动修复建议和 ONEKEY 的合规引擎，持续优化安全基线。
四、Q&A：常见问题解答
Q1：Mend 和 ONEKEY 是竞品关系吗？能不能只用一个？
A：不是竞品。Mend 覆盖源代码和开源依赖层，ONEKEY 覆盖固件和二进制层，二者的分析对象和技术手段不同。对于只涉及纯软件的项目，Mend 单独即可；只涉及固件分析的项目，ONEKEY 单独即可。但 CRA 合规要求覆盖产品的所有可执行层，因此同时包含固件和软件的产品通常需要两者配合。
Q2：两层 SBOM 合并后，数据量会不会很大？
A：会。一个中等复杂度的 IoT 产品，源码层 SBOM 可能包含 200-500 个组件，固件层 SBOM 可能额外包含 100-300 个底层库。合并后的产品级 SBOM 通常在 500-1000 个组件量级。Mend 和 ONEKEY 均支持 CycloneDX 的层级结构，可以通过分层展示来管理复杂度。
Q3：CRA 合规是否强制要求同时覆盖固件和软件？
A：CRA 条文要求覆盖"产品中所有具有数字元素的组件"，ENISA 的实施指南进一步明确包含固件层。如果产品含固件但 SBOM 仅覆盖应用层，在合规审计中会被认定为不完整。
Q4：整合方案的实施成本如何？
A：Mend 和 ONEKEY 均为商业授权产品，授权成本取决于扫描的项目数量和组织规模。实施层面，主要成本在于流程整合和团队培训，通常需要 1-2 个月完成试点到全面推广。
Q5：如果我们的固件是第三方供应商提供的，还需要用 ONEKEY 吗？
A：需要。CRA 要求制造商对供应链中的所有组件承担安全责任，即使固件由第三方提供。ONEKEY 可以对供应商交付的固件镜像进行独立分析，验证其 SBOM 的准确性，并发现供应商可能未披露的安全问题。
Q6：Mend 支持 C/C++ 项目，这和 ONEKEY 分析固件有什么区别？
A：Mend 的 C/C++ 支持是针对源码层面的依赖分析（如 CMake、Conan 等包管理器的依赖检测），需要能访问源代码。ONEKEY 分析的是编译后的二进制固件镜像，无需源代码。二者的分析阶段和输入数据完全不同。