ThreatZ 面向卡车、客车与非道路车辆的网络安全
ThreatZ 以运行乘用车项目群的同一方式运行商用车项目群的网络安全工程：一个拥有多个变体与市场的项目群，每个 ECU 或系统一个项目，TARA、SBOM 与 CVE 匹配、事件指挥、供应商工作区，以及 ISO/SAE 21434 工作产品。平台不区分车辆类别。它不做的事，是判定哪项法规适用于你所在市场的车辆类别：专用车与非道路车辆可能不在 UN R155 范围之内，不暗示任何覆盖，每个类别的适用范围在任何人依赖之前按市场逐一确认。
1 · 车辆类别
车辆类别与法规适用范围
平台不因类别而改变；义务会。下表是为本站签署确认的车辆类别矩阵，保留了全部保留性表述。凡单元格写着“待确认”，那是该声明当前的状态，而非占位符：它要在任何人依赖之前，与你的认证或型式批准负责人按市场逐一确认。
| 类别 | 典型定位 | 对项目群意味着什么 |
|---|---|---|
| M1 乘用车 | 产量最高，周期最短 | UN R155 / R156 在范围内；变体与市场扇出最大。此处列为商用车类别的比较基准行——请确认没有任何目标市场将 M1 排除在外。 |
| M2 / M3 客车与长途客车 | 载客，车队运营 | 与 M1 相同的监管框架——类别适用性与时间表待按市场确认。运营商是会提问的第三方；可用性压力既是他们的，也是你的。 |
| N1–N3 卡车（轻型至重型） | 服役期长，车队运营 | 更长的支持义务——类别细节待确认；车联网与远程诊断暴露面；停机带来直接的收入损失。 |
| O 类挂车 | 经常被遗忘 | 凡装有至少一个 ECU 即予处理——重量等级与市场待确认。容易被低报。 |
| 专用车 / 非道路车辆 | 特种车身，小批量 | 可能不在 R155 范围之内。不暗示任何覆盖；类别与市场在依赖之前确认。 |
各类别适用范围在依赖之前按市场逐一确认。本表中没有任何内容声明各类别之间等同、把欧盟 CRA 义务附加到经型式批准的车辆上，或说明多阶段制造的成品车辆归谁承担义务——这些是本页在下文各节中提出的问题，而非给出的答案。完整矩阵与签署说明：系统供应商页面上的车辆类别。
2 · 工作流
适用于商用车项目群的工作流
卡车、客车或挂车项目群比乘用车项目群更依赖平台的六个地方。每一项描述的都是 ThreatZ 今天在做的事，正如 OEM、Tier-1、建模、供应链与事件响应页面所记载的那样。凡监管答案尚无定论之处，均以问题的形式写出。
一个项目群，多个变体与市场
一个项目群汇集构成整车项目的各个安全项目；一个项目是单个 ECU 或系统的分析范围，在项目群层级的架构上以边界画出。变体与客户项目是基线的分叉：重新绑定，只分析有差异之处。型式批准针对特定配置授予，而基线让“究竟批准了什么”成为可检索的状态——批准本身设有四眼原则关卡。
长服役期与支持窗口
N 类车辆的服役期比轿车长，签署确认的矩阵记录为更长的支持义务——类别细节待确认。这个窗口持续多久、依据哪项法规文书，是我们按市场逐一提出的问题：它是 UN R156 的软件更新义务吗？欧盟 CRA 的任何支持期究竟是否附着于经型式批准的车辆，还是只附着于单独投放市场的数字产品（例如车联网单元）？本页不回答这个问题。平台所做的是：按基线对每个软件单元的 SBOM 进行版本管理，把每次重新导入与上一次交付做差异比对，并在项目群保持开启的整个期间持续将组件与漏洞源进行匹配。
多阶段制造与车身制造商
卡车或客车底盘经常由车身制造商或第二阶段制造商完成。因此，子系统的网络安全证据在被主管机构审阅之前要经过两家制造商之手——而成品车辆的义务由谁承担，是我们提出的一个现实问题，并非平台裁定的事项。ThreatZ 给这位读者的，是一份为从未在场的一方冷读而构建的记录：具名的锚点、逐行的作者归属、只追加的历史，以及一个明确声明的结局，按受众预设渲染。
车联网与远程诊断作为 TARA 中的暴露面
车队运营的车辆默认带有车联网与远程诊断接口，矩阵把这一暴露面列在 N 类之下。在 ThreatZ 中，车联网控制单元与任何其他 ECU 一样是一个项目：它的接口与信号成为 TARA 资产，攻击路径分析对到达它的路径进行评级，可行性可在同一批路径上按攻击潜力、CVSS 或攻击向量评级。本页没有任何内容声称与车联网后端相连或接入车队遥测数据：暴露面在这里被分析，而非被运营。
跨 OEM 项目群的供应商证据
一家向多个商用车 OEM 供应同一 ECU 家族的 Tier-1，只需将其建模一次作为 Security Blueprint，再按客户项目群克隆并分析增量。在 OEM 一侧，供应商在 OEM 的流程内执行：一则安全通告向受影响的项目派发一个子事件，携带 OEM 的指令与声明的准则，供应商在自己的项目中处理，而项目群是唯一的出口关卡。实体级 RBAC 让同一租户内一家客户的工作对另一家客户不可见。
车队地图：从零件号到各市场的注册车辆
供应商针对项目基线申报其交付的 ECU 零件号；ThreatZ 将其与项目群按 VIN 持有的零件号匹配。于是一项发现拥有一条追溯路径——软件组件 → 软件单元 → 系统组件 → 零件号——并由此到达各市场已部署的车辆。车队与风险地图按市场显示车辆数、活跃 CVE 与风险等级（US、DE、CN、JP、BR、AE；其余归入“其他”）；追溯地图把一个市场下钻到受影响的 VIN。两者均为 Enterprise 层级视图。
3 · 实例推演
一个实例推演：一个重型卡车项目群、一个车联网 ECU、一则安全通告
示意性 — 并非客户下方数字为虚构，用以展示链条的形态。它们不是任何客户的数据，各市场的时钟也刻意保留为“按已确认的法规文书”：哪项法规适用于某一市场的 N3 车辆、时间表如何，由认证负责人确认，而非由本例假定。
| 步骤 | 平台上发生的事 | 示例数字（示意） |
|---|---|---|
| 1 · 项目群 | 一个 N3 重型卡车项目群。每个 ECU 或系统是一个项目；车联网控制单元（TCU）是其中之一，由一家在联邦项目中工作的 Tier-1 供应。 | 6 个变体（3 种驾驶室 × 2 种动力总成），11 个 ECU 项目，注册车队分布在 2 个已映射市场（DE、BR） |
| 2 · 零件号 | 该 Tier-1 针对其基线上传 TCU 零件号。ThreatZ 将其与项目群按 VIN 持有的零件号进行精确且不区分大小写的匹配。 | 2 个修订版：TCU rev B 匹配 9,800 个 VIN，rev C 匹配 5,700 个 VIN |
| 3 · 通告到达 | 一条针对某 TLS 库的 CVE 发布。确定性的 SBOM 联接仅在 rev B 的软件单元中找到它；精确联接不会被拉伸去套 rev C。一位具名工程师确认锚点，确认连同何人、何时一并记录。 | 1 条 CVE，1 个软件单元，仅 rev B |
| 4 · 受影响的变体与市场 | 从已确认的锚点出发，链条沿软件单元 → 系统组件 → 零件号 → 各市场的 VIN 运行。车队与风险地图点亮这两个市场；追溯地图列出 VIN。 | 6 个变体中的 4 个；9,800 辆车：DE 7,900 辆，BR 1,900 辆 |
| 5 · 时钟 | 时钟按法规、按市场，从注册车队出发启动——凡该市场有适用于此类别的法规文书之处。没有报告文书的市场被记录为“无”，这与“不适用”是两个不同的事实。 | 按各市场已确认的法规文书——此处不作假定 |
| 6 · 严重性 | 从已锚定的关联出发，沿四个影响轴计算。凡可达集合在任何一个轴上都未评级，记录即声明严重性未计算，并指出缺失了什么。 | rev B 已计算；rev C 未录入任何猜测 |
| 7 · 修复 | 一个子事件被派发到该 Tier-1 的项目，携带项目群的指令与准则。修复由重新导入的物料清单证明——显示该库已升至清除此发现的版本；证据在存储前经失败即关闭的校验。 | 1 个子事件；1 次 CycloneDX 重新导入；1 个组件变更 |
| 8 · 结局 | 事件以事先声明的四种结局之一关闭——已修复、已缓解、已推迟、不适用。报告按受众预设渲染，包括一份主管机构包，全部来自同一份只追加记录。 | 结局：已修复；渲染了 2 个报告预设 |
本表中的每一项机制都在事件响应页面与供应链页面上有所描述；只有数字是虚构的。本例不说明 DE 或 BR 的车队是否属于某项针对 N3 的特定法规文书——那是第 5 步留给认证负责人的问题。
4 · 范围限制
范围限制
请在演示讲解之前读完这些。它们是本页刻意不作的声明。
- 非道路车辆与专用车可能不在 UN R155 范围之内。不暗示任何覆盖。哪些类型被排除、在哪些市场，以及“底盘 + 特种车身”的划分是否在底盘制造商身上留下部分义务，均在依赖之前按市场逐一确认。
- 不声称任何卡车专用协议包。本页不声称提供 J1939、ISOBUS 或其他重型车辆协议库，也不声称提供车联网或车队管理集成。系统模型由建模页面所列的导入格式构建，或在画布上绘制。
- 不涉及农业与工程机械标准。ThreatZ 将其工作产品映射到 ISO/SAE 21434、UN R155/R156、GB 44495，以及（在该法规文书适用之处）欧盟 CRA 第 14 条的报告时限。不声称映射到任何农业或非道路机械标准。
- 各类别时间表按市场逐一确认。M2/M3 的适用性与时间表、N1–N3 的类别细节以及 O 类挂车的重量等级下限，在签署确认的矩阵中均标为“待确认”，本页保持原状。此处不把任何欧盟 CRA 义务附加到经型式批准的车辆上。
- 与型式批准主管机构的关系不在范围内。ThreatZ 产出制造商证据所依据的记录。它不是认证，不向任何主管机构提交任何材料，也不说明多阶段制造中哪家制造商承担成品车辆的义务。
5 · 常见问题
常见问题
ThreatZ 是否覆盖 UN R155 下的卡车、客车与挂车？
ThreatZ 不区分车辆类别：项目群、项目、TARA、SBOM 与事件工作流对 N3 卡车和 M1 轿车以同样方式运行。UN R155 或 R156 是否适用于你所在市场的车辆类别、时间表如何，由你的认证负责人按市场逐一确认。平台不判定适用性，本页也不作此声明。
非道路或农业设备在范围内吗？
专用车与非道路车辆可能不在 UN R155 范围之内，不暗示任何覆盖。你仍可以作为一项工程练习为这台机器建模、运行 TARA 并跟踪其 SBOM，但 ThreatZ 不会把这些工作映射到农业或非道路标准，本页也不声称任何此类映射。类别与市场在依赖之前确认。
ThreatZ 是否自带 J1939 或 ISOBUS 协议库？
不声称提供此类库。系统模型由建模页面所列的导入格式构建，例如 ARXML、System Composer、EA XMI、ODX/PDX/CDD 与 DBC，或在画布上绘制。来自这些来源的总线、接口与信号成为 TARA 资产。卡车或农业专用的协议包不属于本页所描述的内容。
当车身制造商完成底盘时，义务由谁承担？
这是我们提出的问题，而非平台回答的问题。卡车或客车底盘经常由第二阶段制造商完成，因此证据在被主管机构审阅之前要经过两家制造商之手。ThreatZ 提供的是一份从未打开过你平台的一方也能冷读的记录：具名的锚点、逐行的作者归属，以及一个明确声明的结局。
车队地图如何到达一辆注册车辆？
供应商针对项目基线上传 ECU 零件号，ThreatZ 将其与项目群按 VIN 持有的零件号进行精确且不区分大小写的匹配。于是一项发现从软件组件追溯到软件单元、系统组件、零件号，再到各市场的车辆。车队与风险地图是 Enterprise 层级视图。
带来一个卡车或客车项目群。
我们按你的形态跑完这条链。
带上变体数量、你注册车辆的市场，以及一个让你担心的 ECU。我们在运行中的构建上从安全通告走到注册车队——并把法规适用性的问题留在它该在的地方：你的认证负责人那里。