2026 年 9 月 11 日，欧盟《网络弹性法案》（CRA）漏洞通报义务正式生效。距今刚好 7 天，"带数字元素的产品"制造商面对 24 小时预警、72 小时通报的时钟已经开始倒计时。但真正卡住很多企业的，是另一个问题：新漏洞披露时，固件和软件分属两套管理体系，没人能快速给出统一答案。
固件安全和软件供应链安全，究竟能不能整合？本文从艾体宝 Mend + ONEKEY 联合方案出发，介绍整合的可行性、方案架构、核心能力与适用场景。
一、固件安全与软件供应链的割裂困境
同时包含固件与应用软件的产品------工业网关、医疗设备、智能终端、车载系统等------安全管理普遍处于"双轨并行、互不相通"的状态，典型痛点有四：
- 视角割裂：软件侧由应用团队用源码 SCA 工具管理，固件侧由嵌入式团队靠逆向分析和人工排查，产品整体安全状况没有统一视图。
- 重复劳动：同一个开源组件可能同时出现在固件和应用软件中，漏洞披露后两边各自排查、手工对齐，同一个 CVE 被评估两次，结论还可能不一致。
- SBOM 不统一：源码层清单与固件层清单由不同工具产出，格式不同、版本不同步，面对审计，两份清单对不成一份覆盖产品全栈的完整清单。
- 漏洞优先级不统一：两侧评级标准不一致------软件侧的高分漏洞可能在实际调用路径上根本不可达，固件侧的中分漏洞却真实可利用，没有统一排序，修复资源就会投错方向。
困境的根源不在某个团队做得不够，而在于固件与软件从未被当作同一个产品的组成部分来管理。而 CRA 的监管对象恰恰是"产品"------要求覆盖所有可执行层。
二、整合的可行性：为什么可以、为什么必要
先看"为什么可以"。整合并非技术设想，而是建立在三个现实支柱之上：
支柱一：标准格式已经互通。 源码层与固件层 SBOM 都可以用 CycloneDX / SPDX 行业标准格式输出，格式统一，两层组件清单才具备合并对账的基础------这也是 ENISA 实施指南判断"所有可执行层"覆盖的前提。
支柱二：漏洞数据有统一锚点。 固件与软件的漏洞最终都归集到 CVE 等公开漏洞库。以 CVE 为关联键，同一组件在两层可被关联、去重、对比。
支柱三：监管要求本就统一。 CRA 以"带数字元素的产品"为监管对象，ENISA 实施指南进一步明确：仅覆盖应用层而忽略固件层的 SBOM 不满足合规要求。监管方要的从来是一套口径一致的证据。
再看"为什么必要"。通报时限已经生效：24 小时预警要能说清"是否受影响、哪一层受影响"，72 小时通报要给出完整的影响评估。固件与软件若仍分开管理，仅核对影响范围就要横跨两套体系，通报材料更难保证口径一致。对要在欧盟市场销售的产品而言，整合不是可选项，而是合规的必答题。
三、Mend + ONEKEY 联合方案架构
艾体宝 Mend + ONEKEY 联合方案采用"双轨并行、统一汇合"架构，两个平台各管一层、标准对接：
- **软件轨（Mend）**：部署在源码侧与 CI/CD 流水线，负责源码 SCA 扫描、静态安全检测、许可证风险分析，生成源码层 SBOM，推动依赖修复。
- **固件轨（ONEKEY）**：部署在固件构建与出货侧，打包完成后自动触发分析，从二进制镜像逆向生成固件 SBOM，覆盖 ARM / MIPS / RISC-V 等嵌入式架构，并识别硬编码密钥、不安全配置等固件特有风险。
- 三个对接接口：数据接口------两层 SBOM 均以 CycloneDX / SPDX 标准格式输出，可合并为产品级完整清单；关联接口------以 CVE 为锚点，跨层关联与去重漏洞；交付接口------统一输出产品级漏洞视图与合规报告。
这套架构不改变两侧原有工作方式，被整合的只是产出侧的数据与视图。
四、核心能力：一个漏洞事件的全链路处理
整合之后，一个新漏洞在方案内的处理路径是完整闭环：
- 双轨 SBOM，各管一层：Mend 源码层 SBOM 与 ONEKEY 固件层 SBOM 随产品版本持续生成，覆盖产品全部可执行层。
- 软件侧可达性分析：Mend 追踪漏洞函数在应用中的实际调用路径，过滤"存在但不可达"的无效告警，聚焦真实风险。
- 固件侧可利用性评估：ONEKEY 关联 CVE 数据库，结合固件实际运行环境评估漏洞是否真正可利用，避免仅凭评分盲目处置。
- 统一漏洞视图：软件漏洞与固件漏洞汇入同一视图，关联去重，同一组件在两层的实际风险一目了然，优先级排序有了统一依据。
- ENISA 报告一致输出：基于统一视图，受影响产品、版本与处置状态可直接整理为预警与通报材料，无需临时拼凑两套数据。
五、适用场景
凡同时包含固件层与应用软件层的产品，都在联合方案覆盖范围内：
- 工业 IoT：网关、边缘计算设备等固件内含大量开源组件，云管理平台与配置工具属于软件层；
- 医疗设备：设备固件、上位机软件与云服务需一体管理，证据链要求更高；
- 智能家居：设备固件、手机 APP 与云平台构成三层结构，组件清单横跨多层；
- 车联网：车载固件与车载应用并存，要求可追溯的组件清单；
- PLC / 工控系统：控制器固件是核心，上位机软件与工程组态工具同样是产品软件供应链的一部分。
这些场景的共性是：产品作为整体出售，安全管理却容易被拆成两半，而 CRA 要求制造商对整体负责。
六、CRA 合规价值：统一视图是通报时限的前提
CRA 的通报节奏不给割裂留余地：24 小时预警要求快速确认影响范围与受影响层级，72 小时通报要求更完整的影响评估。
割裂体系里，这两步都依赖跨团队、跨平台的人工核对，时限几乎不可能满足；联合方案中，统一漏洞视图直接给出受影响的产品、版本与层级，双轨 SBOM 提供覆盖所有可执行层的完整组件清单，证据链天然一致。产品上市后，双轨 SBOM 随版本迭代同步更新，合规证据始终是当前状态。
对已经进入或准备进入欧盟市场的制造商，整合的价值可以概括为一句话：把"带数字元素的产品"的合规义务，变成一套可执行、可验证的日常流程。
七、常见问题 Q&A
Q1：固件和软件分属不同团队，联合方案如何分工协作？
A：各管一层、统一出口。软件团队在 CI/CD 流水线中运营 Mend，固件团队在构建流程中运营 ONEKEY，安全或合规团队负责汇合处的统一视图与报告输出，两侧不需要改变原有工作方式。
Q2：两层漏洞评级冲突时，统一视图里按哪边的评分为准？
A：统一视图不是二选一取评分，而是叠加上下文。以 CVE 为锚点，可达性结论与可利用性评估都标注在对应漏洞条目上，优先级由"在产品中是否真实可利用"综合判定。
Q3：已经上市的产品，需要重新做一次完整评估吗？
A：建议做。CRA 义务覆盖产品上市后的整个周期，SBOM 需持续维护。对存量产品，一次完整的固件分析加源码扫描建立组件基线，之后随版本迭代增量更新即可。
Q4：如何判断自己的产品是否需要固件 + 软件整合管理？
A：问三个问题：产品是否含固件或嵌入式镜像？是否有配套应用、云平台或配置工具？是否在欧盟市场销售或准备进入？前两问都是"是"且与欧盟市场相关，就需要双轨整合管理；纯软件或纯固件产品，管好对应一侧即可。
Q5：整合时 SBOM 格式选 CycloneDX 还是 SPDX？
A：两者都是行业标准格式，Mend 与 ONEKEY 均支持。关键是两轨约定统一的格式与版本规范，确保合并时组件信息可以对账；如果已有客户或审计方指定了格式，直接沿用即可。
结语
9.11 生效第 7 天，CRA 合规已经进入"用证据说话"的阶段。固件安全与软件供应链安全从来不是两件事，而是同一个产品的两个侧面。Mend 管软件，ONEKEY 管固件，两者以标准 SBOM 格式和 CVE 锚点对接，汇成统一漏洞视图与一致的合规证据链------这就是"固件安全和软件供应链安全能否整合"这个问题的完整答案。