4. CSMS体系构建

UNECE R155 的核心并不是要求某一款车型“绝对不被黑”，而是要求车辆制造商建立一套可持续运行、可审计、可追溯、可改进的网络安全管理体系（CSMS）。CSMS 是组织级能力，不是项目级补丁。它把网络安全从“研发末期的测试活动”提升为覆盖概念、开发、生产、运维、报废全生命周期的治理机制。理解 CSMS 的构建，关键在于看清四件事：框架如何分层、流程如何贯通、角色如何分工、文档如何留痕。

一、CSMS 框架：从治理到证据的四层结构

CSMS 的体系框架可以理解为四层：治理层、管理层、执行层、证据层。治理层由企业最高管理层负责，确定网络安全方针、资源投入、风险接受准则和合规责任；管理层由网络安全管理部门负责，制定流程、标准、模板、审核机制；执行层由研发、生产、采购、售后、IT/OT 等部门在具体项目中落实威胁分析、安全需求、测试验证、漏洞响应；证据层则沉淀为政策文件、流程记录、风险评估报告、测试报告、监控日志、审计结论等，用于向认证机构证明体系真实运行。

这四层不是简单的组织架构图，而是责任与证据的传递链。治理层提出“可接受风险”，管理层把它翻译成“可执行流程”，执行层把它变成“工程活动”，证据层再把工程活动还原为“可审查事实”。如果缺少任何一层，CSMS 就会退化为纸面文件或零散技术活动。

二、组织级流程：把项目活动变成可重复能力

CSMS 的流程必须“组织级”而非“项目级”。项目级流程依赖个人经验，组织级流程依赖标准动作。一个可落地的 CSMS 至少应包含以下主流程：

• 资产与接口识别流程：识别车辆、ECU、总线、无线接口、云端、诊断口、OTA 通道等资产，形成资产清单和接口清单。
• 威胁分析与风险评估流程（TARA）：按 ISO/SAE 21434 方法识别资产、威胁、攻击路径、影响与可行性，输出风险等级和安全目标。
• 安全需求与设计流程：把安全目标转化为可验证的安全需求，落实到架构、通信、诊断、刷写、密钥管理等设计活动。
• 测试与验证流程：包括功能安全测试、渗透测试、模糊测试、漏洞扫描、合规检查，并保留测试证据。
• 漏洞与事件管理流程：建立漏洞接收、分级、修复、验证、披露、召回或 OTA 修复的闭环。
• 供应链管理流程：对供应商提出网络安全要求，获取其 CSMS 证据、SBOM、漏洞响应承诺和接口安全说明。
• 监控与持续改进流程：量产后的威胁情报监控、日志分析、事件响应、管理评审和体系更新。

这些流程之间不是并列关系，而是输入输出关系。资产清单是 TARA 的输入，TARA 输出安全目标，安全目标驱动安全需求，安全需求驱动测试用例，测试结果和漏洞信息又反馈到风险库和设计改进。流程贯通后，CSMS 才能形成“识别—评估—控制—验证—监控—改进”的闭环。

三、角色与职责：RACI 让责任不悬空

CSMS 失败最常见的原因不是技术不足，而是职责不清。建议用 RACI 矩阵明确每个流程的负责人、执行人、被咨询人和知情人。以下是一个简化示例：

表中 R 为执行负责，A 为最终问责，C 为被咨询，I 为被通知。关键原则是：每个流程只能有一个 A，否则会出现“人人有责等于无人负责”；同时，A 不一定由网络安全部门担任，例如供应商准入的 A 可以放在采购或供应商质量，但网络安全部门必须拥有否决权或技术审核权。

四、政策与文档体系：让体系“看得见、查得到、可追溯”

R155 审核关注的是“你说你做了，证据在哪里”。因此文档体系必须分层、编号、受控、可追溯。建议分为四级：

1. 一级：方针与政策，如《车辆网络安全方针》《CSMS 管理手册》，由最高管理层批准。
2. 二级：流程与制度，如《TARA 管理程序》《漏洞管理程序》《供应商网络安全管理程序》《事件响应程序》。
3. 三级：指南与模板，如《TARA 模板》《安全需求规格模板》《渗透测试报告模板》《SBOM 模板》。
4. 四级：记录与证据，如风险评估报告、测试报告、评审纪要、培训记录、审计报告、漏洞处置单。

五、案例与误区复盘

某车企在首次 CSMS 审核中被开出不符合项：企业有完整的 TARA 报告，但无法证明 TARA 是在设计阶段完成的，也无法证明安全需求被测试覆盖。根本原因是流程虽然存在，但没有与研发门禁绑定，TARA 成了事后补文件。整改后，该企业把 TARA 完成作为概念阶段门禁条件，把安全需求覆盖作为设计评审条件，把渗透测试通过作为量产放行条件，并把所有证据自动归档到 CSMS 平台，最终通过审核。

综上，CSMS 体系构建的本质是：用治理层定方向，用管理层定规则，用执行层做活动，用证据层留痕迹，再用监控与评审推动持续改进。只有把框架、流程、角色和文档四者咬合起来，CSMS 才不是一堆文件，而是组织真正具备的车辆网络安全能力。