芯耀
与非AI
487
引言
据中国机电产品进出口商会报道，2025年我国机电产品出口2.3万亿美元，占货物出口总额的61%。其中支持联网、含软件的产品占比极高，且均在 CRA 覆盖范围内。
2026年9月11日，欧盟《网络弹性法案》（Cyber Resilience Act，CRA）的漏洞与事件通报义务正式生效。法规对24小时、72小时义务做出严格要求，对于出口欧盟的企业而言，合规准备刻不容缓。
2026年9月11日，欧盟《网络弹性法案》（Cyber Resilience Act，CRA）的漏洞与事件通报义务正式生效。根据要求，当制造商获知产品存在被积极利用的漏洞，或发生影响产品安全性的严重事件后，需要在规定时限内完成通报：漏洞和事件分别对应不同的 24 小时预警、72 小时正式通报及后续最终报告要求。（漏洞类与事件类的期限、起算点不同，见下图）
通报统一通过欧盟网络安全局（ENISA）运营的单一报告平台（SRP）提交，并同步提供给指定的协调 CSIRT。CRA 明确规定了提交主体与方式，可对于制造商而言，真正的挑战并不只是“如何提交”，而是在有限时间内准确回答：究竟哪些产品、哪些版本受到了影响，以及这些产品投放到了哪些欧盟成员国。
24小时通报，首先回答“哪些产品受影响”
漏洞情报到达时，企业获得的信息通常从组件或漏洞本身开始，例如组件名称、受影响版本和 CVE 编号。
但 CRA 的通报要求最终会落实到具体产品，包括产品名称、产品版本及投放的成员国等信息。这意味着企业需要建立一条从漏洞 → 组件 → 固件 → 产品型号 → 产品版本 → 市场的关联链路，其中任何一个环节缺少数据，都可能左右企业对产品影响范围的判断，最终考验的是企业是否具备从漏洞快速定位到具体产品的能力。
根据 CRA 第 14 条规定，从组件到产品，企业只有24小时时间迅速完成归因与通报，否则后续流程也将举步维艰。
三个现实痛点，难以找到受影响产品
CRA 附件一要求制造商记录并维护软件物料清单（SBOM），记录产品所使用的软件组件，并采用机器可读的格式。但从现实数据来看并不容乐观。今年 8 月一份针对 200 家德国工业企业的调查显示，只有 18% 把 SBOM 做到覆盖所有受影响产品。综合来说，回答“哪些产品受影响”的难点有以下三种：
1.软件组成信息不完整
SBOM 的价值不仅在于满足 CRA 合规要求，更在于建立产品与软件组件之间的可追溯关系，提高产品识别能力。
但在实际产品中，软件组成信息未必完整。特别是嵌入式设备，第三方模块、芯片厂商提供的 BSP、外购软件组件等，可能以预编译二进制的形式存在。企业如果主要依赖源代码扫描，这部分组件就可能无法被完整识别。
因此，当漏洞情报出现时，企业可能只能确认“产品使用过这个组件”，却无法立即确认具体哪个型号、哪个固件版本使用了受影响版本的组件。
这也是为什么，对于已经存在的固件，仅依赖传统源码扫描往往不足以支撑完整的产品影响判断。
2.版本命中≠产品实际受影响
即使企业已经建立了组件与产品之间的关联，也不能简单通过版本号判断漏洞是否真实存在。
例如，安全补丁可能已经回补到稳定分支，漏洞代码也可能并未进入最终固件；此外，处理器架构、编译配置等因素，同样可能影响漏洞是否实际存在。
因此，需要进一步确认：
受影响版本是否真的进入了最终产品？漏洞相关代码是否存在于实际固件中？
这一判断区别于单纯的版本匹配，需要结合固件中的实际组件、模块以及其他技术信息进行分析。
对于 24 小时通报场景而言，如果大量时间用于排除与实际产品无关的漏洞告警，就会进一步压缩企业完成影响判断和通报的时间。
3.信息权限分散，影响跨部门响应配合
产品影响判断通常并不只掌握在网络安全团队手中。
固件构建信息可能在研发团队，软件组件信息可能由不同产品线维护，供应商组件信息掌握在采购或供应链团队，而产品型号及投放市场信息又可能分散在产品、销售或运营体系中。
如果企业没有提前明确漏洞通报的责任链路和信息调取权限，接到漏洞情报后，还需要临时协调不同团队获取数据。
因此，CRA 通报能力不仅是技术问题，也涉及人员、流程和权限。
SBOM 再完整，如果无法及时获得固件和产品信息，也很难在规定时间内完成产品级影响判断。
尽管 SBOM 清单这项义务在 2027 年 12 月 11 日才会正式生效，但具备清单整理和漏洞通报能力已经迫在眉睫。
已经上市的产品，同样纳入通报范围
除了新产品，企业还需要关注一个容易被忽略的问题：
此前已经投放市场的产品，并不会因为 CRA 的其他义务尚未全面适用，就自动排除在漏洞通报之外。
CRA 对部分既有产品确实设置了过渡安排。2027 年 12 月 11 日之前上市、且之后未进行实质性修改的产品，在符合条件的情况下，不需要重新履行部分安全设计、符合性评估和 CE 标识等要求。但根据第 69 条相关规定，第 14 条规定的漏洞与事件通报义务仍然适用于这类产品。
因此，对于企业而言，需要关注的不仅是当前正在销售的新型号，也包括此前已经投放市场、目前仍可能受到漏洞影响的产品。
这类产品在实际管理中往往面临更高的信息追溯难度：产品可能已经停止生产，但仍在客户现场运行；历史固件、软件组件及构建信息也可能不像新产品一样完整。
对于这部分产品，可以从现有固件包入手，通过二进制分析还原软件组成，再逐步建立：产品型号 ↔ 固件版本 ↔ 组件版本之间的对应关系，并结合产品投放信息进一步确认受影响的市场范围。
企业可以开始做的三项准备
1.提前完成 SRP 申报准备
提前配置相关人员的 EU Login 账号及 MFA，明确申报人员，并确认对应的协调 CSIRT。这些工作可以在漏洞事件发生之前完成，避免在通报时限开始计算后再临时确认人员和流程。
2.建立明确的漏洞通报响应链路
明确谁负责接收漏洞情报、谁负责判断漏洞是否影响产品、谁负责内部确认和 SRP 提交，并为关键角色设置备份人员。
同时，应确保相关人员能够及时获取产品固件、SBOM、漏洞信息和产品投放记录，并将关键判断过程和时间节点做好留档。
3.将 SBOM 纳入产品研发流程
对于新产品，可以将 SBOM 生成纳入软件构建流程，随着固件版本持续更新。
对于已经上市的产品，则可以从现有固件反向建立软件组成信息，逐步补齐产品、固件与组件之间的关联。
艾体宝 ONEKEY，如何缩短从“漏洞”到“产品”的判断路径？
在 CRA 通报场景下，组织分工和响应机制需要企业自行建立，但在固件分析、SBOM 构建以及漏洞影响判断等环节，自动化工具可以帮助企业缩短排查时间。
艾体宝 ONEKEY 平台支持直接分析二进制固件，在无需源代码的情况下识别固件中的软件组件并生成可核查的 SBOM，同时结合漏洞情报与固件实际内容进行关联分析。
对于传统源码扫描难以覆盖的第三方二进制组件，可以通过固件分析补充软件组成信息；在漏洞判断环节，则进一步结合实际固件中的组件、模块、架构等信息，对漏洞是否实际存在于当前产品进行分析，帮助企业减少单纯基于版本匹配产生的无关告警。
同时，ONEKEY 支持通过 API 与 GitLab CI/CD 等研发流程进行集成，使固件安全分析能够进一步融入持续的软件供应链管理。
从 CRA 漏洞通报的实际需求来看，企业最终需要建立的并不只是一个软件组件清单，而是一条能够快速追溯的产品安全数据链：漏洞 → 组件 → 固件 → 产品 → 市场。当漏洞情报进入后，企业能够快速回答“哪些产品受影响”，才有可能在规定时限内完成后续的通报、处置与整改。
对于正在为 CRA 做准备的企业而言，可以先从一个实际产品的固件开始验证：现有软件组成信息是否完整？一个漏洞出现后，能否快速定位到具体型号和固件版本？
这也是检验企业当前产品安全与漏洞响应能力的一个直接切入点。
