中国汽车零部件供应商出口欧洲：UN R155 要求准备哪些网络安全证据？

一家中国 Tier 1 企业收到欧洲整车厂的项目询问。邮件要求提交网络安全风险评估、风险处理记录和漏洞响应办法。工程团队手里有 TARA Excel、网络拓扑图和测试报告，却很难解释这些文件之间的关系。真正的难题不是缺少文件，而是拿不出一条能被复核的工程证据链。

UN R155 对供应商提出的是哪类要求？

UN R155 针对车辆网络安全及网络安全管理体系。法规中的证明义务主要落在申请车辆型式批准的整车制造商身上。第 7.2.2.5 条要求制造商说明如何管理与签约供应商及服务提供商相关的依赖和风险。这不等于所有零部件供应商都直接持有同一项法规审批义务。^S1S2

但合同会把工作传到供应链。整车厂往往需要 ECU 供应商说明控制器的边界、外部接口、已识别的威胁、采用的控制以及剩余风险。交付范围应由项目合同、安全接口协议和客户要求确定，不能只凭一份通用清单推断。

一套能被客户核对的证据，至少应讲清什么？

系统和责任边界。 先明确哪个 ECU 属于供应商交付范围。列出诊断接口、通信网络、更新路径、后台依赖和第三方软件。对不由本团队负责的环节，写明交接对象。

资产与损害后果。 固件完整性、诊断权限、车载消息和密钥都可能成为分析对象。每个资产要对应明确的损害情景，而不是只有一串资产名称。

威胁与攻击路径。 对每条重点威胁，记录攻击者从哪里进入、经过哪些接口、希望影响什么资产。发现路径不成立时，要留下判断依据。

风险处理与验证。 记录选定的处理方式、相关网络安全目标、实施控制和测试结果。控制已经规划、已经实现和已经验证，是三种不同状态。

交付后的持续管理。 软件版本、SBOM、漏洞调查、变更记录和负责人要能够关联。一次审核通过，不代表以后再也不需要更新分析。

以电机控制器为例：客户到底想看到什么？

假设一款动力系统控制器支持经诊断接口执行固件更新。工程师提出的威胁是：未经授权的编程操作改变电机控制固件。可能的损害情景是错误的扭矩控制或控制器无法正常运行。

这只是分析起点。团队还要验证网关是否允许诊断请求到达目标 ECU，编程服务有哪些权限检查，固件签名是否在安装前验证，以及故障状态如何处理。未核实的假设必须单独标记。不能把“诊断接口存在”写成“攻击必然可行”。

证据链可以这样组织：架构接口指向资产，资产连接损害情景，损害情景连接威胁，威胁连接攻击路径，风险处理指向控制和验证记录。客户追问某个高风险结论时，工程师能沿着这条链找到原始依据。

供应商最容易犯的三个错误

第一，给客户发送一份长表，却没有说明版本和批准状态。第二，把安全控制的设计意图写成已完成验证。第三，车辆架构或软件发生变化后，继续引用旧版 TARA。三种情况都会增加技术澄清的轮次。

建立稳定的 ID、记录责任人和保留版本差异，比增加更多描述性文字更有价值。ISO/SAE 21434 提供覆盖概念、开发、生产和运行维护阶段的网络安全工程框架。^S3

QuickTARA 如何帮助准备这些材料？

QuickTARA 把 ECU 架构、资产、损害情景、威胁、攻击路径和风险处理放在有关联的工作流中。团队可以追查风险来自哪里，哪些措施已经记录，哪些决定仍待审批。平台支持自托管部署，也可以输出面向不同读者的工程报告。

评估软件时，请直接要求供应商演示一个真实的追溯动作：从一条风险进入对应攻击路径，再找到控制和报告内容。演示比功能清单更容易判断工具是否适合自己的交付流程。

常见问题

UN R155 会直接要求每家中国零部件厂申请认证吗？ 不应这样理解。先区分车辆型式批准责任、供应商合同要求和具体产品交付范围。^S1S2

准备了 ISO/SAE 21434 TARA 就足够了吗？ 一份 TARA 并不自动覆盖客户需要的全部过程、验证、监测和变更证据。还需要核对项目要求。

现在最值得做什么？ 从一个正在交付的 ECU 开始，把架构、风险、控制和验证记录连起来，再检验客户是否能独立复核。