全球法规全景：核心法规解读
各位工程师朋友，今天我们来聊聊座舱软件合规必须面对的那几张“考卷”。
说实话，我刚入行那会儿，法规还没这么密。现在不一样了——UN R155、UN R156、ISO 21434、GB/T 40861，一个都不能少。你想想看，座舱里跑着地图、语音、支付、车载微信，哪一项出安全问题都是大事。
我个人习惯把这几部法规分成两类：强制性的准入门槛和技术落地的指导手册。下面我们一个一个拆开看。
UN R155：网络安全管理的“入场券”
UN R155，全称《关于网络安全及网络安全管理系统（CSMS）的车辆型式认证统一规定》。
说白了，它就是一张“入场券”。从2022年7月起，欧盟市场的新车型必须通过R155认证。没有它，你的车连欧洲海关都过不去。
R155的核心要求是什么？我总结为三点：
- 建立CSMS（网络安全管理系统）——企业得有组织、有流程、有人负责安全。
- 识别并管理网络安全风险——从设计阶段就开始做威胁分析和风险评估（TARA）。
- 持续监控与响应——车卖出去不是结束，得盯着路上的安全事件。
我在项目中遇到过一家OEM，为了赶R155认证，临时搭了个安全团队。结果呢？流程没跑通，TARA文档写了300页，但跟实际开发脱节。嗯，这里要注意：R155不是让你写论文，是让你真正把安全做进产品里。
关键点：R155认证的是“管理体系”，不是单一产品。企业必须先拿到CSMS证书，才能申请具体车型的型式认证。
UN R156：软件更新的“交通规则”
UN R156，全称《关于软件更新及软件更新管理系统（SUMS）的车辆型式认证统一规定》。
R156跟R155是“孪生兄弟”。R155管安全，R156管更新。为什么需要它？因为现在的车越来越像手机，OTA升级成了常态。但汽车不是手机——升级出问题，可能出人命。
R156的核心要求包括：
- 建立SUMS（软件更新管理系统）——谁负责发版？谁负责测试？谁负责回滚？
- 更新包完整性验证——确保升级包没被篡改。
- 用户知情与同意——升级前得告诉用户：升级什么、影响什么、能不能拒绝。
- 回滚能力——升级失败，车不能变砖。
我曾经帮一家Tier 1审查OTA流程，发现他们的回滚方案只写了“如果升级失败，请到4S店处理”。这显然不行。R156要求的是自动回滚，或者至少是用户能自行恢复的机制。
避坑指南：我曾经见过一个项目，R156认证时被卡在“用户同意”环节。原因是升级弹窗只有“确认”按钮，没有“拒绝”选项。记住：用户必须有选择权。
ISO 21434：技术落地的“施工图”
ISO 21434，全称《道路车辆——网络安全工程》。
如果说R155是“考纲”，那ISO 21434就是“教材”。它把R155的要求拆解成具体的技术活动：怎么做TARA？怎么设计安全架构？怎么验证？怎么响应事件？
ISO 21434覆盖了全生命周期：
| 阶段 | 核心活动 | 输出物示例 |
|---|---|---|
| 概念阶段 | 威胁分析与风险评估（TARA） | TARA报告、安全目标 |
| 开发阶段 | 安全架构设计、安全编码 | 安全需求规范、安全用例 |
| 验证阶段 | 渗透测试、模糊测试 | 测试报告、漏洞清单 |
| 生产与运维 | 安全监控、事件响应 | 监控日志、事件报告 |
我个人觉得，ISO 21434最实用的部分是TARA方法。它教你如何系统性地找出风险点，并给每个风险定级。举个例子：座舱的语音助手如果被恶意唤醒，可能泄露车内对话。TARA会把这个场景的威胁等级标出来，然后你决定要不要加声纹识别。
注意：ISO 21434是标准，不是法规。但它被R155和R156直接引用。换句话说，你按ISO 21434做，R155/R156认证会顺利很多。不按它做？也行，但你要证明你的方法同样有效——这通常更难。
GB/T 40861：中国的“本土化答卷”
GB/T 40861，全称《道路车辆 信息安全工程》。
这是中国的推荐性国家标准，2021年发布。它基本沿用了ISO 21434的框架，但做了本土化调整。为什么需要它？因为中国的道路环境、监管要求、数据安全法规（比如《个人信息保护法》）跟欧洲不一样。
GB/T 40861的几个特色：
- 强调数据安全——座舱里收集的用户数据（人脸、声纹、位置）必须合规处理。
- 与国内法规对齐——比如《网络安全法》《数据安全法》《个人信息保护法》。
- 推荐性而非强制性——但别高兴太早。虽然它叫“推荐性”，但工信部的很多审查会引用它。你不做？审查时可能被要求补充材料。
我记得有一次帮国内一家车厂做合规差距分析，发现他们的数据加密方案用的是国际算法，没通过国密局认证。GB/T 40861虽然没有强制要求国密，但国内审查时，国密算法几乎是默认选项。嗯，这个坑大家要注意。
四部法规的关系：一张图看懂
下面这张图展示了四部法规的定位和关系。我建议你把它存下来，以后做合规规划时直接参考。
实际项目中的合规策略
讲完理论，说说实战。我在多个项目中总结了一套“四步走”策略：
- 定基线——先搞清楚你的目标市场。出口欧洲？R155/R156是硬门槛。只在国内卖？GB/T 40861是主要参考，但建议也看ISO 21434，因为国内审查越来越严。
- 建体系——别急着写代码。先把CSMS/SUMS的流程搭起来。谁负责安全？谁审批更新？事件响应怎么走？这些没理清，后面全是坑。
- 做TARA——针对座舱软件，识别关键资产（语音、导航、支付、摄像头），做威胁分析。我建议用微软的STRIDE方法，配合ISO 21434的TARA模板。
- 持续验证——安全不是一次性工作。每个迭代都要做安全测试，包括静态代码扫描、动态模糊测试、渗透测试。
个人经验：我建议在项目启动阶段就引入合规审查。别等到开发完了再补，那成本至少翻三倍。我曾经见过一个项目，因为没提前做TARA，后期发现座舱的蓝牙协议有高危漏洞，不得不重新设计通信模块——整整延期两个月。
好了，这一章的内容就到这里。法规是死的，但应用是活的。理解每部法规的定位和关系，你就能在合规审查中游刃有余。