存量车辆事件响应的最佳平台，是那个会明确说出自己对老旧车队有哪些未知、却仍能产出可辩护记录的平台。评估候选平台时，应依据车辆锚定、对TARA缺失的诚实处理、暴露面重建、供应商参与、证据校验和记录完整性来打分，而不是数功能。
在搜索“存量车辆事件响应最佳平台”的买方，心里通常有一支具体的车队：这些存量车辆（已交付、仍在役的早期车型）在组织采用 ISO/SAE 21434 之前设计，在 UN R155 适用于该车型之前获得型式批准，如今仍在路上行驶，车上的调制解调器、蓝牙协议栈和诊断接口当年只做过粗略的威胁建模，甚至从未做过。当一份安全通告指向其中某辆车的某个组件时，PSIRT 负责人、VSOC 经理和 CSMS 负责人需要的是一份审核员、客户乃至法庭日后都能循迹追溯的记录。
本指南不对供应商排名。它给出一组任何平台都可据以打分的标准，说明当历史 TARA 不完整或缺失时平台应当如何表现，逐步走完从通告到证据的工作流，并指出任何工具都无法消除的局限。在这些标准上得分高的平台，就是对所讨论车队而言的最佳平台，无论它叫什么名字。
为什么存量车辆事件响应是一个不同的评估问题
工具评估通常针对正在开发的车队，而不是十二年前已经交付的那支；对于那么老的车辆，有四项假设不再成立。
工程基线是残缺的：在当前 CSMS 建立之前开发的车型可能有安全分析，却没有网络安全的相关项定义、攻击路径或网络安全目标；即便有 TARA，往往也早于后来加装的远程信息处理单元，或早于通过服务活动追加的 OTA（空中下载）能力。软件定义汽车中的网络安全债务是设计阶段的问题，存量车辆事件响应则是它在运营阶段的账单。
软件构成没有文档：以 CycloneDX 或 SPDX 格式编写的物料清单直到最近才在多数项目中出现，而关于某个 ECU 上到底运行着什么，唯一的记录可能是一家已经被并购两次的供应商手中的服务备件档案。车辆总数难以统计：哪些 VIN 在哪个市场搭载了哪个零件号，这些信息分散在生产、保修和售后服务系统里，而这些系统从未为安全目的打通过。
法规地位因车辆和市场而异：部分存量车型因其类别和批准日期而不在 UN R155 范围之内，但 CSMS 义务、产品责任和对客户的承诺仍然要求做出响应。平台必须按市场记录适用性。
为建模完善的车队打造的平台会填满每一个字段。为存量车队打造的平台知道哪些字段填不了，并且明说。
存量车辆事件响应平台的评分标准
对存量车队而言，“最佳”的有用定义很窄：在输入不完整的情况下，其记录仍能经受独立审查的平台。这意味着对未知项坦诚，锚定于车辆而非工作项（参见为什么汽车事件管理不是工单管理），以及一套外部人员读得懂的关闭词汇。在脚本化演示中填写评分卡，每项标准按 0 到 3 分打分，并对与车队真实缺口相对应的行加权。
| 标准 | 关注点 | 演示中如何验证 |
|---|---|---|
| 车辆锚定 | 事件关联到组件、软件单元、系统组件、零件号和 VIN；关联由具名人员确认 | 把一份通告锚定到一个没有 SBOM 的组件；是由人确认，还是工具径自断言 |
| TARA 缺失 | 对“无 TARA”、“TARA 早于架构变更”、“未计算”有各自独立的状态；没有默认评级 | 给出一个没有风险评估的车型；问严重度字段显示什么 |
| 暴露面重建 | 依据上传数据建立零件号到 VIN 再到市场的链条；未匹配的零件列出而非丢弃 | 上传一份分隔符和大小写不一致的零件清单；核对合计数能否对账 |
| 严重度依据 | 依据已确认的关联在具名影响维度上推导；记录显示使用了哪些输入 | 移走一个“严重”评级背后的一项输入；评级是改变还是弃权 |
| 按市场的时限 | 依据已登记车队按法规和市场启动；记录“无适用法规”；超时显示为违约 | 登记一支车型不在范围内的车队；确认显示“无适用法规”而不是空白 |
| 供应商参与 | 派发到供应商自己的工作区，附指令和标准；项目方是唯一的关闭出口 | 尝试从供应商账号关闭子事件 |
| 证据与关闭 | 在工作开始前声明证明方式；证据按“失败即拒绝”校验；固定结局；“延期”属于暂挂 | 上传一份格式错误的 SBOM 作为证明；尝试关闭一个延期项 |
| 记录完整性 | 仅可追加，逐行记录作者；面向各受众的报告出自同一组行 | 编辑一条过去的更新；检查原始内容是否保留 |
| 回溯性 TARA | 从事件创建风险，关联到组件并纳入版本管理 | 从事件创建一个风险；打开它并检查关联是否完整 |
另有三行是通过/不通过项：在 CycloneDX 和 SPDX 存在时平台能够读取它们，不存在时则依据声明的关联开展工作；平台能部署在组织记录可能存放的任何位置，且从不需要源代码；平台从 SIEM 接收信号并向工单系统输出任务，而不取代二者中的任何一个。
平台应如何处理不完整或缺失的历史 TARA
这个问题把为存量车辆事件响应而设计的平台与为之改造的平台区分开来。ISO/SAE 21434 期望由风险评估来指导对网络安全事件的响应；对于从未做过风险评估的车型，平台必须支持一种有章法的替代方案，同时不假装它就是原始评估。
| 情形 | 处理方案 | 平台必须支持什么 | 残余局限 |
|---|---|---|---|
| 该车型没有 TARA | 事件范围内评估：以受影响功能作为相关项，只纳入通告中的攻击路径和损害场景 | 从事件创建风险，关联到组件，作为首个修订版纳入版本管理 | 不是车型级 TARA；不能宣称超出该功能的覆盖范围 |
| TARA 早于一次架构变更 | 对已变更资产做增量评估，点明已失效的假设 | 比较修订版，标记被推翻的假设，保留原件 | 旧基线的其余部分仍未经审视 |
| TARA 仅以电子表格形式存在 | 作为带来源信息的参考工件导入，绝不作为计算数据 | 附上作者、日期和版本；标记为“已声明、未验证” | 不能据此计算严重度 |
| 兄弟变型有 TARA | 借用，并附明确的变型差异说明 | 追溯哪些变型共用该组件；记录来源 | 变型漂移可能使评级失效 |
| TARA 在供应商手中 | 通过派发的事件、附声明的标准向其索取 | 在存储前校验提交内容 | 供应商的合同可能已经到期 |
| 无可重建之物 | 将严重度记录为未计算；由具名的决策人依据暴露面证据作出决定 | 带理由的弃权；附残余风险接受的决策记录 | 决策依据的是暴露面，而不是经分析的影响 |
有两条实践贯穿每一行：范围受限的评估应在 TARA 版本控制下成长为持续维护的评估；声明绝不能变成计算，因为电子表格里的评级一旦作为数字导入，在下一位读者眼里就成了分析结论。ISO/SAE 21434 TARA 指南给出了完整方法；对存量车辆而言，变化的只是范围。
从通告到证据的调查工作流
到达与锚定
通告连同到达时间戳、所称受影响组件、版本范围和来源一并记录；对存量车队而言，来源往往是研究人员或客户，因此手工录入的质量必须与自动化情报源相当。随后把通告关联到承载它的组件：有物料清单时做精确匹配，否则做名称匹配，再做基于图谱的匹配，每一步都允许判定为“无法匹配”。在下游任何环节把这一关联当作事实之前，须由具名人员确认。
重建
从已确认的组件出发，链条延伸到软件单元、系统组件、零件号，直至各市场中搭载该零件的车辆。对存量车辆而言，这一步会暴露缺口：未匹配的零件号、无法解析所属区域的 VIN、完全没有该组件记录的变型。好的平台会把它们作为事实列出，所用方法见将 ECU 零件号追溯到车队暴露面。
评估与设门
严重度依据已确认的关联，在组织定义的各影响维度上推导。当没有任何 TARA 提供损害场景、因而没有一个维度能够评级时，平台记录“严重度未计算”并指明缺少了什么；后续的确认可以补算。随后依据已登记车队按法规和市场启动时限；没有适用法规之处作为事实记录，错过的时限则显示为违约。
派发、验证与关闭
事件派发到每一个承载该组件的供应商项目，附上供应商必须满足的指令和标准；供应商在自己的工作区内工作，而项目方始终是关闭的唯一出口，正如OEM 与供应商事件升级框架所述。整改证明从一组固定的方式中预先声明，并在存储前校验：一份处于已修复版本的物料清单，或者，对于永远不会再更新的 ECU，一项经验证的缓解措施或一项已接受的残余风险。汽车事件关闭证据清单列出了每一种具名结局所需的内容。
实例：一份针对十二年车龄车机的通告
假设一家 Tier-1 向某 OEM 项目供应了一款联网车机，该项目十二年前投产，覆盖三个市场的 11 个变型，目前仍有约 18 万辆在册。该供应商被并购了两次；现在的所有方持有服务备件记录和一份二进制归档，但没有 SBOM，也没有网络安全分析。一份通告指出，该车机据信使用的某个蓝牙协议栈库存在漏洞。
第一个候选平台把通告锚定到整车级别的“信息娱乐系统”，按默认映射赋予“高”评级，并在全部三个市场启动时限。没有任何内容解释严重度是如何得出的，也不说明哪些变型搭载了该库。
在第二个平台上，精确的 SBOM 匹配一无所获，并如实说明。名称匹配提出四个零件号；一位具名的供应商工程师确认了三个，对第四个提出异议。由于没有损害场景可供评定任何影响维度，严重度被记录为未计算；完成事件范围内评估后，计算结果为“高”，两种状态都留在记录上。时限只在有适用法规的那一个市场启动；另外两个市场记录为无适用法规。零件号上传匹配到 118,000 个 VIN，并列出 2,400 个区域未解析的 VIN。供应商收到一个附带 OEM 标准的子事件，因该车机无法通过 OTA 更新而提出一项配置缓解措施，上传验证证据，项目方随后将该发现关闭为“已缓解”，残余风险由一位具名的项目经理接受。
供应商参与与多阶段制造车辆
存量事件发生时的组件所有方，往往已不是当年签署网络安全接口协议的那一方（如果当年有这份协议的话）；平台应允许向当前所有方派发，并在派发时声明标准。
车辆类别增加了第二层复杂性。城市客车与长途客车与乘用车处于同一法规框架之下，但类别适用性和时间表须按市场确认。卡车承担更长的支持义务，其类别细节有待确认。挂车在装有至少一个 ECU 时纳入范围，但重量等级和市场有待确认，且很容易被漏报。专用车辆和非道路车辆可能不在 UN R155 范围之内；不应暗示任何覆盖，并且在任何人依赖之前，应按市场逐类确认适用范围。
卡车或客车底盘往往由改装厂完成上装，因此记录可能由一个从未参与过的当事方来阅读；具名的锚定、声明的结局和逐行的作者记录，正是为这种“冷读”而设。
平台应当说明、买方应当接受的局限
没有任何平台能消除存量车队中的缺口；最佳平台只是让它们可见。
- 暴露面受上传数据所限。 如果生产记录从未记载哪个零件装进了哪个 VIN 对应的车辆，平台可以列出未匹配的零件，却无法凭空造出映射。
- 范围受限的评估不是车型级 TARA。 整车覆盖需要一次有计划的评估，通常与一次软件更新或一项停止支持决定挂钩。
- 弃权有代价。 “未计算”可以辩护，却无法用来排定工作优先级；仍然需要一条仅凭暴露面证据采取行动的规则。
- 适用性是法律判定。 平台记录组织为每个市场声明的适用法规；它不代为决定。
- 供应商证据取决于供应商能力。 到期的合同或丢失的归档是项目风险，平台能把它暴露出来，却无法治愈。
- 是证据，不是认证。 平台支持 ISO/SAE 21434 持续活动和 UN R155 量产后监控所需的证据；它不认证合规。SIEM 仍负责检测，工单系统仍负责分派任务；参见建设车辆安全运营中心。
关联记录如何帮助存量车队
上述标准描述的是一条关联记录：通告到组件，组件到软件单元和系统组件，系统组件到零件号，零件号到各市场中的车辆，每一项风险、每一家供应商和每一项决策都附着其上。ThreatZ 正是围绕这条记录构建的。其 Traceability Map（追溯地图）以一个发现为锚点，跨供应商、项目和区域一路追到受影响的 VIN；一个发现只有在链条完整时才会抵达某个市场，而地图会显示链条在哪里断开。
在暴露面方面，供应商从项目基线声明其供应的 ECU 零件号，平台将其与项目方的零件号匹配，每个基线显示哪些零件已匹配、哪些未匹配，以及受影响的 VIN 数量。在事件上，ThreatZ 记录已确认的锚定及其确认人和确认时间、计算出的严重度或记录在案的弃权、按市场的时限（无适用法规之处如实记录）、附带 OEM 标准派发的子事件、存储前按“失败即拒绝”校验的证据，以及四种具名结局之一，全部落在一份仅可追加、逐行署名的记录上。报告按受众预设生成。私有云或本地部署——支持物理隔离（air-gapped）环境。
这些都无法补写一份从未写过的 TARA；但它意味着，范围受限的那份评估从一开始就与促成它的事件关联在一起。
常见问题
平台能为从未做过 TARA 的车辆计算严重度吗？
无法诚实地做到，平台也应如此说明。严重度由损害场景的影响和攻击可行性推导而来；没有对受影响功能的评估，任何影响维度都无法评级。为存量车队设计的平台会记录“严重度未计算”，指明缺少了什么，并在范围受限的评估完成后再行计算。
组织应当为每一种存量车型重建完整的 TARA 吗？
通常不应作为第一步。为临近停止支持的车辆做车型级 TARA 很少会改变任何决定，而且这些精力会与响应工作争夺资源。可行的路径是对受影响功能做事件范围内评估，作为一份随每次事件成长的 TARA 的首个修订版纳入版本管理；完整评估则依车队规模和剩余支持期限安排。
评估如何避免被精心打磨的演示左右？
自己提供输入。供应商准备的数据集里每个零件号都已匹配、每个组件都在 SBOM 中。带上一份真实通告、一个没有 TARA 的车型、一份保留了真实不一致之处的零件号清单，再加一个扮演供应商的第二账号，然后给平台记录缺口的方式打分。
供应商已经不存在了怎么办？
平台可以向当前的组件所有方派发并附声明的标准，记录其回复，但它无法产出继任方手中没有的证据。记录应显示派发、标准、答复或答复的缺失，以及具名决策人仅凭暴露面证据处置该发现的决定。这条链条是可辩护的。
UN R155 适用于已在路上行驶的存量车辆吗？
适用性取决于车辆类别、市场和车型获得批准的日期，且须按市场确认。许多存量车型不在该法规的范围之内，但 CSMS、ISO/SAE 21434 持续活动、产品责任和客户期望仍然要求响应。平台应把每个市场的适用法规作为声明的事实记录下来，包括无适用法规的情形。
- 以记录定义最佳： 存量车辆事件响应的最佳平台，是在输入不完整时其记录仍能经受独立审查的那个。
- 显式记录未知项： “未评估”、“未计算”、“不适用”和“无适用法规”必须是彼此独立的记录状态；默认值或空白即为不合格。
- 锚定于车辆： 事件关联到组件、软件单元、系统组件、零件号和 VIN，并由具名人员确认该关联。
- 诚实处理 TARA 缺失： 事件范围内评估、增量评估和“已声明、未验证”的导入，每一种都记录其局限。
- 依据真实数据重建暴露面： 未匹配的零件号和未解析的区域是需要列出的事实，不是可以丢弃的噪声。
- 派发时附带标准： 供应商在自己的空间内依据声明的标准工作，而项目方始终是关闭的唯一出口。
- 校验证据并固定词汇： 证明方式预先声明，校验不通过的证据予以拒绝，结局固定，延期项绝不关闭。
- 接受既定局限： 暴露面受上传数据所限，范围受限的评估不是车型级 TARA，证据也不等于认证。
VxLabs Security 相关延伸阅读
权威参考
- ISO/SAE 21434:2021 道路车辆 — 网络安全工程 — ISO/SAE，2021
- 联合国第 155 号法规 — 网络安全与网络安全管理体系 — UNECE，2021
- 联合国第 156 号法规 — 软件更新与软件更新管理体系 — UNECE，2021
- 欧盟法规 (EU) 2024/2847 网络弹性法案（欧盟 CRA） — 欧盟，2024
- ISO/PAS 5112 道路车辆 — 网络安全工程审核指南 — ISO，2022