CRA 报告时钟已经启动，难点不在于填表，而在于如何在 24 小时和 72 小时内从一条外部信号走到一个站得住脚的产品立场。在事件发生之前就固定产品范围、知悉规则和证据追溯的供应商，报告时依据的是受控事实，而不是事后重建。
网络弹性法案（欧盟 CRA）的报告时钟已经正式运转。自 2026 年 9 月 11 日起，受 CRA 管辖的含数字元素产品的制造商必须报告正被积极利用的漏洞以及影响产品安全的严重事件。第一个时限可能在知悉后 24 小时内到来，更完整的通报则须在 72 小时内提交。汽车供应商 CRA 报告因此不再是一个规划议题，而成为 Tier-1 PSIRT、产品安全、合规和 CSMS 负责人每天面对的运营义务。
对汽车供应商而言，困难很少在于打开一张监管表单。困难在于，在调查仍在推进的同时，要确定发生了什么、哪些产品在范围内、哪些客户和市场可能受到影响，以及哪些证据支撑初始立场。
报告义务由此暴露出一个运营层面的问题：组织能否在时钟到期之前，从一条外部信号走到一个站得住脚的产品决策？本指南涵盖各项时限、在任何事件发生之前就应完成的准备、每次提交背后的证据，以及一个时钟在范围尚未明确时就已启动的实例。
CRA 报告时限一览
CRA 规定的是分阶段的报告序列，而不是一次性提交。每个阶段的目的不同，对完整性的要求也不同，把它们混为一谈是团队浪费时间的第一种方式。
| 阶段 | 时限 | 适用对象 | 应以什么为依据 |
|---|---|---|---|
| 预警 | 知悉后 24 小时内 | 正被积极利用的漏洞，或影响产品安全的严重事件 | 受控事实：触发因素、知悉时间戳、候选产品、尚未核实的内容 |
| 通报 | 知悉后 72 小时内 | 同一事件，经初步评估之后 | 结构化影响评估：受影响产品与版本、利用条件、缓解措施、带责任人的未决问题 |
| 最终报告（漏洞） | 不迟于纠正或缓解措施可用后 14 天 | 正被积极利用的漏洞 | 根因、措施、验证证据、受影响群体、客户沟通 |
| 最终报告（事件） | 72 小时通报后一个月内 | 严重事件 | 完整事件记录、纠正行动、供应商回复、审批 |
这一序列的两个特征决定了后续的一切。每个时限都锚定在知悉的那一刻，因此组织对"知悉"的定义本身就是一项合规控制。而预警明确不是最终的技术答案，所以团队必须能够把已确认的事实与工作假设区分开来。已经梳理过汽车供应商的欧盟 CRA 合规路线图的供应商会发现，报告正是同一条追溯链在运营端的终点。
在事件发生之前确认产品范围
CRA 在汽车领域的适用性需要逐产品进行细致分析。部分产品或功能可能属于行业专门法规的管辖范围，而独立上市销售的 ECU、远程信息处理单元、诊断软件、车队应用、后装设备及其他数字产品则可能需要单独考虑 CRA 的适用。企业不应假定整车型式认证自动回答了产品组合中每一项的问题。两种制度之间的互动在欧盟网络弹性法案与 UNECE R155 对比中有专门分析。
法务团队应当确认正式范围。产品安全和工程团队则必须让这个范围可用，因为备忘录里的法律意见在漏洞利用公开的那个早晨是查不出来的。产品组合记录至少应为每个产品标明：
- 法律意义上的制造商，以及将产品投放市场的实体。
- 产品族及当前仍在支持期内的软件版本。
- 各版本销售或部署所在的市场。
- 负责的 PSIRT 联系人与升级路径。
- 支持期限与支持终止日期。
- 相关监管路径：CRA、行业专门制度、两者兼有，或仍在法律审查中。
设想一家典型的 Tier-1，假设有 40 个产品族：28 个交付给型式认证项目的整车集成控制单元、6 个以供应商自有品牌销售的后装远程信息处理和车队设备、4 个维修车间诊断工具和 2 个车队应用。这几组产品的监管路径可能各不相同，甚至同一产品族内，同一硬件通过不同渠道销售时路径也可能不同。工程部门不决定法律答案，但答案必须记录在产品记录之上，做到不开会就能查到。
这项工作属于事件发生之前的运营模型。在 24 小时窗口已经开始计时之后再去确定法律上的产品边界，会带来本可避免的延误，而延误会层层叠加：范围不确定会卡住客户清单，客户清单又会卡住暴露评估。
在时钟定义"知悉"之前先定义它
知悉时间戳锚定了每一个报告时限，因此组织需要一条经共识的规则来界定知悉何时开始，并留有记录说明该规则是如何被应用的。私人邮箱里的一条消息或 VSOC 队列里一条未分诊的告警，不应成为一个看不见的起点。
一条可操作的知悉规则会列出各个接收渠道，以及每个渠道的识别事件：
- 与受支持产品中某个组件匹配的漏洞情报告警。
- OEM 依据合同披露或升级协议发出的通知。
- 到达 PSIRT 队列的 VSOC 或车队监控升级。
- 通过公开联系方式收到的研究人员或协调机构披露。
- 内部发现，或供应商自身的通知。
对于每个渠道，规则要说明什么算作识别、由谁记录时间戳、记录存放在哪里。举例来说：OEM 的安全联系人在周五 17:40 给某位指定工程师发了邮件，该工程师在周一 08:15 才读到。没有规则，组织就有两个相差两天多的候选时间戳，而且两者都没有书面依据。有了把所有渠道都路由到受监控 PSIRT 队列的规则，这个问题在被提出之前就已经有了答案。
一条未分诊的消息不是知悉的延迟。它是一个已经在计时、却没人看得见的时限。
OEM 自身的报告时钟可能取决于供应商何时通知它，因此知悉规则与OEM 与供应商事件升级框架中的合同承诺应当一起设计。
最初 24 小时：建立在受控事实上的预警
欧盟委员会将第一次提交描述为预警。它不被期望包含最终的技术答案，但仍应建立在受控事实而非假设之上。
一个务实的第一天工作流应回答六个问题：
- 是什么触发了知悉，知悉是在何时被记录的？
- 该事件涉及的是正被积极利用的漏洞，还是影响产品安全的严重事件？
- 根据现有证据，哪些产品族和版本可能受到影响？
- 哪些团队和供应商必须参与评估？
- 哪些已知、哪些仍在调查、哪些表述需要验证？
- 谁有权批准该预警？
这些问题对应着一个大致的时间序列。最初两小时内，PSIRT 登记信号及其来源、时间戳和候选产品关联，并开立事件记录，此后所有产物都挂接在这条记录之下。第二到第八小时，团队跑一遍候选范围：SBOM 匹配、架构查询、客户配置记录。第八到第十八小时，起草预警，分为三个带标签的区块：已确认、调查中、尚未评估。剩余时间留给授权审批人评审并提交。
带标签的区块是预警的核心。"该组件存在于三个已交付构建中；在交付配置下的可达性正在调查；后装变体尚未评估"，这样的表述比自信地宣称没有影响、或含糊地说正在处理，都更站得住脚。
72 小时通报：从信号到有依据的影响评估
下一阶段要把早期信号转化为结构化的影响评估。团队应将漏洞或事件与受影响的产品架构、软件组成、已部署版本、可用缓解措施以及已知的利用条件关联起来。
对汽车供应商而言，这通常需要来自多个来源的证据，每个来源回答一个不同的问题。
| 证据来源 | 它回答的问题 | 典型失效模式 |
|---|---|---|
| 每个已交付构建的 SBOM | 组件是否存在，以及是哪个版本 | SBOM 按发布分支而非按已交付构建维护 |
| 软件架构 | 存在漏洞的函数在交付配置中是否存在且可达 | 架构只是一页幻灯片，而不是与软件记录关联、可查询的模型 |
| TARA | 该暴露会激活哪些损害场景和威胁场景 | TARA 早于当前软件基线 |
| 测试结果 | 可达性已被证实或排除；补偿控制已被验证 | 测试没有与其验证的控制措施关联 |
| 客户配置记录 | 哪些 OEM 项目在哪些市场收到了受影响版本 | 交付记录放在通用工单系统里，没有版本粒度 |
| 供应商回复 | Tier-1 并非作者的子组件状态 | 回复没有时限，也没有记录问了什么 |
SBOM 可以识别出组件匹配，而汽车 SBOM 管理中的实践决定了这种匹配能否按已交付构建而不是按发布分支进行。随后，其余每个来源把这一匹配逐步收窄为产品层面的答案。
72 小时提交应反映当时所能支撑的最佳立场。调查尚未完成之处，记录应如实说明并指派下一步行动。当决策链同时保留证据和不确定性时，可信度会提高：宣称超出证据支撑的确定性会在日后产生更正义务，而遗漏团队已经掌握的证据则会招来"为什么没有使用"的质疑。
最终报告同样需要工程纪律
CRA 还要求提交最终报告。对于正被积极利用的漏洞，最终报告须不迟于纠正或缓解措施可用后 14 天提交。对于严重事件，最终报告须在 72 小时通报后一个月内提交。
这份后期报告无法从零散的邮件片段中可靠地拼凑出来。组织需要在一条可追溯的事件记录中具备以下内容：
- 原始信号、其来源与知悉时间戳。
- 每一次范围变更，以及推动变更的证据。
- 技术分析及其输入：SBOM 匹配、架构查询、TARA 场景、测试结果。
- 带时间戳的供应商请求与回复。
- 处置决策及其理由。
- 纠正或缓解措施的验证证据。
- 客户沟通及其发送到的受影响项目清单。
- 每一次监管提交及其背后的审批。
许多团队正是在这里发现，合规取决于工程追溯性。报告是输出，底层能力则是把一个产品事件与所涉及的确切组件、版本、项目、风险、控制措施、测试和责任人连接起来。
最终报告不是在第 14 天写出来的。它从知悉那一刻起，就在一条记录一条记录地被写下。
五个阶段构成的实用 CRA 报告链
汽车供应商可以围绕五个受控阶段组织工作流，每个阶段产出的结果由下一阶段消费。
- 记录知悉：登记信号、来源、时间戳与初始产品关联。
- 界定暴露范围：将事件映射到产品族、版本、客户、市场与已部署配置。
- 评估影响：将问题与架构、SBOM 记录、攻击路径、TARA 场景和可用控制措施关联。
- 决策并报告：为每个时限保留事实、不确定项、审批与监管提交。
- 验证并关闭：验证纠正措施、更新受影响记录、留存最终证据包。
这条链有意以产品为中心："产品族"、"已交付版本"、"OEM 项目"和"TARA 场景"必须是可查询的记录，而不是工单描述里的文字。最有用的就绪度测试是一次演练：选一条近期触及受支持产品的公告，对着时钟跑完五个阶段，记录时间在哪里丢失。想把自身工具链与这一要求做对照的供应商，可以从对比您当前的方案开始。
对 Tier-1 组织而言，实际问题是这条链中有多少已经存在于工程记录中、有多少是每次事件时重建的；面向 Tier-1 供应商的 ThreatZ概览在这一语境下描述了互联记录的形态。
实例：报告时钟在范围明确之前启动
一家 Tier-1 供应商在 09:10 得知，其远程信息处理模块所使用的一个软件库正被积极利用。该供应商向三家 OEM 交付该模块，但库版本和构建配置因项目而异。在那一刻，团队掌握的信息可能足以启动 CRA 评估，却不足以给出最终的产品影响声明。
第一个受控动作是保留知悉时间戳和候选产品范围。PSIRT 依据知悉规则在 09:25 登记该信号。到 11:00，跨已交付构建的 SBOM 匹配显示，该库存在于全部三个已交付版本中，但分属两个库发行版：项目 A 和 B 收到的是 2.4 版，项目 C 收到的是 2.1 版。公告点名的是 2.4 版。项目 C 被标记为"可能不受影响，待确认"，而不是从范围中移除，因为组件级匹配尚不等于函数级答案。
到下午过半，架构记录显示存在漏洞的函数属于 2.4 构建中的远程配置路径，而项目 B 的交付配置在构建时禁用了该路径。团队将其记录为"调查中的缓解条件"，并指派一名测试工程师加以确认。一份请求发往该库的上游供应商，并记录了发出时间。预警于 17:30 获批并提交：组件确认存在于三个已交付版本；被利用的发行版存在于其中两个；其中一个的可达性正在调查；后装变体尚未评估。
第二天，可达性测试确认项目 B 无法通过被利用的路径到达，而后装变体被确认搭载 2.4 版且路径处于启用状态。TARA 中已经包含针对未授权远程配置的威胁场景，因此直接挂接现有风险立场，而无需重写。72 小时通报补充了有依据的影响评估、处置方向以及更新后的产品范围：项目 A 和后装变体受影响，项目 B 通过配置缓解并附有测试证据，项目 C 因版本不同而不受影响。
修补后的库发行版在第九天可用；漏洞最终报告的 14 天窗口从该措施可用之时起算，而由于每一步都挂接在同一条事件记录上，最终报告就是这条链的一次导出。这个例子说明了为什么 CRA 报告就绪度取决于事件之前的产品追溯性，而不是事件之后的填表。
常见问题
CRA 的 24 小时报告期从何时开始？
报告期从制造商知悉符合报告条件的正被积极利用的漏洞或严重事件之时开始。由于该时间戳锚定了此后的每一个时限，组织应明确定义在所有接收渠道中如何识别、记录和升级"知悉"，以免私人邮箱或监控队列中一条未分诊的消息造成一个看不见的时限。
72 小时通报是否需要最终的根因分析？
不需要。它应基于当时所能支撑的最佳立场，提供 CRA 要求的更完整信息。当范围、根因或处置仍在调查时，提交内容应区分已确认的事实与未决问题，并为下一步行动指派责任人。同时保留证据和不确定性，会让通报更容易辩护、也更容易更新。
CRA 报告与汽车型式认证有何关系？
两种制度可能相互作用，但不能互换。汽车企业应逐产品而非按整个产品组合，判定哪些含数字元素的产品落入 CRA 范围、哪些适用行业专门规则。法律顾问应确认适用性；工程和产品安全团队则必须维护好产品记录，以便信号到来时能迅速执行这一决定。
到了 24 小时节点产品范围仍不确定，供应商该怎么做？
依据受控事实报告，其余内容加上标签。预警不被期望包含最终的技术答案，因此站得住脚的立场是：一个每一项都有证据依据的候选范围、一份对调查中事项的清晰说明，以及为每个未决问题指定的责任人。凭假设移除某个产品，或为保险起见把所有产品都列进去，这两种做法都会削弱记录。
哪些记录必须一直保留到最终报告？
原始信号与知悉时间戳、每一次范围变更及其证据、含 SBOM、架构、TARA 和测试输入的技术分析、带时间戳的供应商请求与回复、处置决策、措施的验证证据、客户沟通，以及每一次监管提交及其审批。从一开始就挂接在一条事件记录上，最终报告就是一次导出；散落在邮件和工单里，它就是一次重建。
- 时钟已经启动：自 2026 年 9 月 11 日起，受管辖的制造商须提交 24 小时预警、72 小时通报，并在措施可用后 14 天或通报后一个月内提交最终报告。
- 事件之前先定范围：逐产品确认法律路径并记录在产品记录上，以免第一天就卡住客户清单。
- 明确定义知悉：列出每个接收渠道、识别事件和时间戳责任人，并将所有渠道路由到一个受监控的队列。
- 预警意味着受控事实：已确认、调查中、尚未评估三个带标签的区块，由指定权限人审批。
- 72 小时立场以证据为基础：按已交付构建的 SBOM、可查询的架构、现行 TARA、已关联的测试以及客户配置记录，各自回答一个不同的问题。
- 最终报告是逐步积累的：每一次范围变更、供应商回复、决策和审批，从知悉那一刻起就挂接在同一条事件记录上。
- 把报告链当作演练来跑：选一条真实公告，对着时钟跑完五个阶段，修复时间丢失的那个阶段。
VxLabs Security 相关延伸阅读
权威参考
- (EU) 2024/2847 号条例——网络弹性法案——欧洲议会与欧盟理事会，2024
- 网络弹性法案概要——欧盟委员会
- 网络弹性法案制造商报告义务——欧盟委员会
- UNECE 第 155 号法规——网络安全与网络安全管理体系——UNECE
- ISO/SAE 21434:2021 道路车辆——网络安全工程——ISO/SAE