简介UN Regulation No.155《关于车辆网络安全与网络安全管理系统CSMS的统一规定》官方PDF文档面向汽车网络安全工程师、法规合规人员及智能网联汽车研发从业者用于理解联合国对车辆网络安全的批准要求与CSMS框架。文档涵盖适用范围M、N类车辆及配备ECU的O类车辆具备L3以上自动驾驶功能的L6、L7类车辆、网络安全与CSMS定义、申请批准流程、合规性互认、更新修订及实施执行等核心章节并附有ECE/TRANS/WP.29/2020/79等修订文件说明可帮助读者系统掌握R155法规的完整条款与落地要点。资源包共1个PDF文件大小约1.34MB内容为联合国正式文本结构清晰、便于检索查阅。目前已有2485人学习下载适合需要对照法规原文开展CSMS建设、认证准备或技术研究的人员参考。1. 从一份被退回的型式认证说起UN R155 到底卡住了谁某车企的电子电气架构团队在 2024 年做欧盟整车型式认证时被审核方退回了一份材料理由只有一句话网络安全管理系统CSMS的适用范围没有覆盖到售后阶段的软件更新链路。团队当时的第一反应是“我们做了渗透测试、也出了报告为什么还不行”。问题恰恰出在这里——UN Regulation No.155 从来不是一份“测一测就过”的技术标准它要求的是一套贯穿车型全生命周期的网络安全管理体系渗透测试只是其中一环。这就是 UN R155 的核心它把网络安全从“项目末期的一次性动作”变成了“企业级的管理能力”。法规正文分两部分一部分是对车辆制造商 CSMS 的认证要求另一部分是对车辆型式认证中网络安全性能的要求。前者管的是“你有没有能力持续管住风险”后者管的是“这台车在具体威胁面前扛不扛得住”。两者缺一不可而且 CSMS 认证是车辆型式认证的前置条件。适合读这篇的人有三类一是正在准备欧盟认证的整车或零部件企业的合规、安全、电子电气架构工程师二是想把 R155 的威胁分析框架落到具体车型开发流程里的技术负责人三是做 TARA威胁分析与风险评估工具链、想理解法规对输入输出到底有什么硬性要求的开发者。接下来的内容按“法规要什么 → 体系怎么搭 → 技术怎么做 → 坑在哪 → 怎么验证”的顺序展开每一步都尽量落到可执行的层面。2. CSMS 不是一份文档把管理体系拆成可运行的四个模块2.1 为什么“写一份网络安全政策”过不了审核很多团队第一次接触 R155 时会把 CSMS 理解成一套文档体系安全政策、流程规范、职责矩阵、记录表单。文档当然要有但审核方真正看的是这些文档有没有被“运行”起来。举个具体的判断点法规要求制造商证明自己能在车辆量产后持续监测威胁、评估影响、并通过软件更新或召回手段响应。如果企业只能拿出一份《网络安全事件响应预案》却拿不出过去一段时间内真实发生过的威胁情报收集记录、影响评估结论和处置闭环审核方会认为体系是“纸面运行”。CSMS 的可运行性体现在四个模块上这四个模块也是我建议在体系搭建时直接按模块划分职责的模块核心活动关键输出物常见责任方治理与组织定义安全政策、分配职责、管理供应商政策文件、职责矩阵、供应商安全协议合规/质量/采购风险管理识别资产、威胁、漏洞做 TARA资产清单、威胁清单、TARA 报告安全工程/架构开发与验证安全需求分解、设计、测试安全需求规范、测试报告、漏洞记录研发/测试监测与响应威胁情报、事件响应、更新管理监测日志、事件报告、更新记录安全运营/售后这张表的用法不是拿去填模板而是用来做差距分析把企业现有流程往四个模块里塞哪个模块塞不进去或者只有空壳那里就是审核的高风险区。2.2 资产识别TARA 的输入质量决定后面所有工作的上限TARA 是 R155 技术侧的核心方法论而 TARA 的第一步是资产识别。这一步做粗了后面的威胁分析和风险评估全是空中楼阁。我见过一个典型翻车案例某团队做资产识别时只列了“车机、网关、T-Box、ECU”这种颗粒度结果威胁分析阶段根本没法判断某个威胁到底影响哪个具体资产最后只能返工重做。资产识别的合理颗粒度应该到“接口 数据 功能”这一层。比如一个 T-Box至少要拆出蜂窝通信接口、GNSS 接口、CAN 接口、诊断接口、OTA 客户端、存储的凭证数据、对外提供的远程控制功能。每个资产再标注它的安全属性机密性、完整性、可用性和依赖关系。# 资产识别的最小数据结构示例 # 用字典描述一个资产字段设计对应 TARA 后续步骤的输入需求 asset { asset_id: TBX-001, # 唯一标识后续威胁分析要引用 name: T-Box 远程控制模块, type: ecu_function, # 资产类型ecu / interface / data / function interfaces: [cellular, can, gnss, diagnostic], data_assets: [vehicle_credentials, location_history], security_attributes: { confidentiality: high, # 凭证泄露影响大 integrity: high, # 控制指令被篡改影响大 availability: medium }, dependencies: [GW-001, CLOUD-AUTH-001], # 依赖的网关和云端认证服务 lifecycle_stage: [development, production, post_production] } # 逻辑说明 # 1. asset_id 是后续威胁清单、风险评估表的主键必须唯一且稳定。 # 2. interfaces 和 data_assets 是威胁分析时枚举攻击面的直接输入。 # 3. security_attributes 用于风险评估阶段计算影响等级。 # 4. dependencies 用于分析级联影响比如云端认证服务不可用会波及哪些功能。 # 5. lifecycle_stage 确保资产在开发、生产、售后各阶段都被纳入管理。参数说明security_attributes 的取值建议用 high/medium/low 三档起步不要一上来就搞五档否则团队内部对“中高”和“高低”的判定会吵得不可开交。dependencies 字段在初期可以只填直接依赖级联分析放到风险评估阶段再做。2.3 威胁分析与风险评估把攻击树和影响矩阵接起来资产清单有了之后威胁分析要做的是“对每个资产枚举可能的攻击路径”。常见做法是结合威胁库比如行业通用的威胁分类和攻击树方法。攻击树的根节点是“攻击者达成某个安全目标”叶子节点是具体攻击步骤。R155 不强制你用哪种方法但要求你能证明分析是系统性的、可追溯的。风险评估则要把威胁和影响对应起来。影响维度通常包括安全人身、财务、隐私、运营。每个维度再分等级。这里有个容易踩的坑很多团队把“攻击可行性”和“影响严重度”混在一张表里打分最后算出一个不伦不类的总分。正确做法是分开评可行性看攻击复杂度、所需权限、机会窗口影响看后果严重度和波及范围。两者都高的威胁才是优先处置项。# 风险评估的简化计算逻辑 # 可行性评分1-5越高越容易实施 # 影响评分1-5越高后果越严重 threats [ {id: T-001, feasibility: 4, impact: 5, asset: TBX-001}, {id: T-002, feasibility: 2, impact: 4, asset: TBX-001}, {id: T-003, feasibility: 5, impact: 2, asset: GW-001}, ] def risk_level(feasibility, impact): # 用乘积做初筛再按阈值分档 score feasibility * impact if score 15: return critical # 必须设计缓解措施并验证 elif score 8: return high # 需要缓解措施或说明接受理由 elif score 4: return medium # 建议缓解可接受残留风险 else: return low # 记录并持续监测 for t in threats: t[risk] risk_level(t[feasibility], t[impact]) print(f{t[id]} on {t[asset]}: {t[risk]}) # 逻辑说明 # 1. 可行性和影响分开评分避免“容易但没后果”的威胁被高估。 # 2. 乘积只是初筛critical 档必须回到攻击树确认是否有遗漏的缓解点。 # 3. 每个威胁的处置结论缓解/接受/转移/规避要记录审核方会查。参数说明阈值 15/8/4 不是法规规定的是企业根据自身风险偏好定的。定完之后要在 CSMS 政策里写清楚并且保持跨项目一致否则审核方会质疑评分的客观性。2.4 供应商管理R155 把责任压在了制造商身上R155 明确制造商对整车网络安全负总责供应商的组件出问题制造商一样要担。这意味着 CSMS 必须覆盖供应商准入、开发接口、变更通知、漏洞通报这几个环节。实操中最容易出问题的是“变更通知”供应商升级了一个库、换了一个通信协议版本如果没有及时通知制造商整车的 TARA 可能就失效了。建议在供应商合同里加三条硬性要求一是安全事件和漏洞的通报时限比如 72 小时内二是组件变更前必须提交影响分析三是供应商的 CSMS 要能提供等效的证据材料。这三条写进去后面审核时能省很多解释成本。3. 从 TARA 到代码把安全需求落到 ECU 和通信层3.1 安全需求分解每条需求都要能追溯到威胁TARA 输出的是威胁和风险等级接下来要把它翻译成可实现的安全需求。翻译的关键是“可追溯”每条安全需求都要能指回它缓解的是哪个威胁。比如威胁“攻击者通过诊断接口刷写恶意固件”对应的安全需求可能是“诊断刷写前必须完成双向认证”和“固件签名验证失败时禁止写入”。# 安全需求与威胁的追溯关系示例 security_requirements [ { req_id: SR-001, description: 诊断刷写前必须完成双向认证, mitigates: [T-001], # 对应威胁 ID asset: TBX-001, verification: penetration_test, # 验证方式 status: implemented }, { req_id: SR-002, description: 固件签名验证失败时禁止写入并记录事件, mitigates: [T-001, T-004], asset: TBX-001, verification: unit_test integration_test, status: implemented } ] # 逻辑说明 # 1. mitigates 字段建立需求到威胁的映射审核时用来证明覆盖完整。 # 2. verification 字段说明这条需求怎么被验证不能只写“已实现”。 # 3. status 用于跟踪未实现的需求要有风险接受记录。参数说明verification 的取值建议统一枚举比如 unit_test、integration_test、penetration_test、code_review、supplier_evidence。枚举统一了后面做覆盖度统计才方便。3.2 车载通信安全CAN 和以太网的分层防护车载通信是 R155 技术侧的重点。CAN 总线本身没有认证和加密机制这是公开事实所以防护要放在网关和 ECU 的应用层。常见做法是网关做报文过滤和速率限制关键控制指令加 MAC消息认证码诊断接口做认证和权限分级。以太网这边TSN 和 SOME/IP 的安全扩展可以用但要注意对实时性的影响。// CAN 报文过滤的伪代码逻辑网关侧 // 只允许白名单内的 CAN ID 通过并对关键 ID 做速率限制 #define MAX_RATE_PER_SEC 50 typedef struct { uint32_t can_id; uint32_t last_timestamp; uint32_t counter; } can_filter_entry; bool can_filter_check(can_filter_entry *entry, uint32_t now) { // 白名单检查不在列表内的 ID 直接丢弃 if (!is_in_whitelist(entry-can_id)) { log_event(blocked_can_id, entry-can_id); return false; } // 速率限制防止重放或洪泛攻击 if (now - entry-last_timestamp 1000) { // 1 秒窗口 entry-counter; if (entry-counter MAX_RATE_PER_SEC) { log_event(rate_limit_exceeded, entry-can_id); return false; } } else { entry-counter 0; entry-last_timestamp now; } return true; } // 逻辑说明 // 1. 白名单是基础但白名单本身要防篡改通常放在受保护的存储区。 // 2. 速率限制的阈值要按报文类型分别设控制类报文阈值低状态类可以高。 // 3. 日志要能上报到安全运营侧否则事后无法追溯。参数说明MAX_RATE_PER_SEC 的取值需要根据总线负载和报文周期实测确定设太低会误杀正常报文设太高起不到防护作用。建议在台架上先跑一遍正常工况取峰值速率的 1.5 到 2 倍作为初始阈值。3.3 OTA 更新链路签名、回滚和断电保护OTA 是 R155 售后阶段的核心场景。更新链路的安全要点有三个固件签名验证、失败回滚、断电保护。签名验证确保只有合法固件能被安装回滚机制确保更新失败后车辆能恢复到可用状态断电保护确保更新过程中断电不会让 ECU 变砖。# OTA 更新包的验证流程车端逻辑 import hashlib def verify_update_package(package, signature, public_key): # 第一步计算包摘要 digest hashlib.sha256(package).digest() # 第二步用公钥验证签名 if not verify_signature(digest, signature, public_key): raise SecurityError(signature_verification_failed) # 第三步检查版本号防止降级攻击 if package.version current_version: raise SecurityError(downgrade_attempt) # 第四步检查包完整性长度、分片校验 if not check_integrity(package): raise SecurityError(integrity_check_failed) return True # 逻辑说明 # 1. 签名验证必须在安装前完成不能边装边验。 # 2. 版本号检查防降级降级可能引入已知漏洞。 # 3. 完整性检查覆盖传输过程中的损坏和篡改。 # 4. 验证失败要记录事件并上报不能静默失败。参数说明公钥的存储要放在受保护的区域比如 HSM 或 TrustZone。版本号比较要处理回滚场景比如售后更换 ECU 后版本可能回退这时候要有单独的授权流程不能简单拒绝。4. 避坑与排查R155 落地中最容易翻车的五件事4.1 现象审核方说 TARA 覆盖不全但没说哪里不全原因通常是资产识别阶段漏了“间接资产”比如云端服务、诊断工具、生产线上的刷写设备。这些资产不在车上但能影响车辆安全。解决方法是把 TARA 的范围从“车辆本身”扩展到“与车辆交互的所有系统”并在资产清单里单独标注生命周期阶段。4.2 现象渗透测试做了但审核方不认原因往往是测试范围和 TARA 的威胁清单对不上。渗透测试只测了车机但 TARA 里列了 T-Box 和网关的威胁。解决方法是让渗透测试的用例直接来自威胁清单每个高危威胁至少有一个对应的测试用例测试报告里要能追溯到威胁 ID。4.3 现象供应商提供的安全证据材料格式五花八门原因是采购阶段没有约定证据格式。解决方法是在供应商准入时提供模板要求供应商按模板提交资产清单、威胁分析、测试报告。模板不用复杂但字段要统一否则后期整合的工作量会大到让人后悔。4.4 现象车辆量产后收到漏洞通报但无法判断影响范围原因是资产清单和物料清单BOM没有关联。解决方法是把资产 ID 和 BOM 里的零件号做映射收到漏洞通报后能快速定位到哪些车型、哪些批次受影响。这个映射建议在开发阶段就建好产后补建的成本很高。4.5 现象安全更新推送到车端后部分车辆更新失败且无法回滚原因是回滚机制没有覆盖所有 ECU或者回滚镜像的存储空间不足。解决方法是在设计阶段就为每个可更新 ECU 预留回滚分区并在台架上做断电、断网、存储满等异常场景的测试。回滚失败的车端要有明确的降级运行策略不能直接变砖。5. 验证与进阶用审核方的视角检查自己的 CSMS5.1 用“证据链”思路做内部预审R155 审核的本质是看证据链完不完整。我一般建议团队在正式审核前做一次内部预审按下面的链条逐条检查检查项证据材料常见缺口资产是否完整资产清单 BOM 映射漏云端和工具链资产威胁是否系统威胁清单 攻击树威胁枚举依赖个人经验风险是否可追溯TARA 报告 评分标准评分标准未文档化需求是否覆盖安全需求规范 追溯矩阵需求与威胁映射缺失验证是否充分测试报告 漏洞记录测试用例未关联威胁售后是否闭环监测日志 事件报告无真实事件处置记录这张表的用法是逐项找证据找不到证据的项就是预审要补的项。补的时候注意证据不是越多越好而是要能形成闭环。比如威胁清单里的每个威胁都要能在需求、测试、监测三个阶段找到对应记录。5.2 监测与响应把“事后补救”变成“持续运行”R155 要求制造商在量产后持续监测威胁。实操中监测的数据来源包括车端安全日志、云端安全事件、行业威胁情报、供应商漏洞通报。这些数据要汇总到一个可查询的平台并且有明确的分类和优先级规则。-- 安全事件表的简化设计用于监测和响应 CREATE TABLE security_events ( event_id BIGINT PRIMARY KEY, vehicle_id VARCHAR(64), -- 车辆标识 asset_id VARCHAR(64), -- 关联资产 event_type VARCHAR(32), -- 事件类型intrusion / anomaly / vuln_report severity VARCHAR(16), -- 严重度critical / high / medium / low detected_at TIMESTAMP, -- 检测时间 source VARCHAR(32), -- 来源vehicle / cloud / supplier / intel status VARCHAR(16), -- 状态open / investigating / resolved resolution TEXT -- 处置结论 ); -- 逻辑说明 -- 1. asset_id 关联资产清单用于快速判断影响范围。 -- 2. severity 和 status 用于排优先级和跟踪闭环。 -- 3. resolution 记录处置结论审核时用来证明响应有效。 -- 4. 建议按 detected_at 做分区方便按时间窗口查询。参数说明severity 的判定规则要提前定义比如涉及安全功能的入侵直接定 critical异常行为定 high漏洞通报按 CVSS 分数映射。规则定好后要定期回顾避免严重度通胀。5.3 一个具体技巧用“红蓝对抗”验证监测有效性监测系统建好后怎么知道它真的能发现问题我常用的方法是做小范围的红蓝对抗蓝队防守方不知道红队攻击方的具体动作红队在台架或测试车上模拟 TARA 里的高危威胁看蓝队能不能在约定时间内检测到并响应。这个测试的价值在于暴露监测规则的盲区比如某些攻击路径没有对应的日志采集点。红蓝对抗的用例要直接来自威胁清单每次选 3 到 5 个高危威胁覆盖不同的攻击面通信、诊断、OTA、云端。测试结束后要复盘检测时间、误报情况、响应流程是否顺畅。复盘结论要反馈到监测规则和响应预案里形成闭环。我自己在这个方向上踩过的最大的坑是早期把 CSMS 当成一个“认证项目”来做文档写完、测试做完就以为结束了。后来才明白R155 要的是一套能持续运行的能力认证只是对能力的阶段性确认。现在我做任何车型的网络安全方案第一件事都是先问“量产后谁来看日志、谁来处置事件、谁来更新 TARA”这三个问题答不上来前面的工作大概率要返工。希望帮到你。本文还有配套的精品资源点击获取