3. CSMS核心概念
在CSMS（车辆网络安全管理体系）中，资产管理、威胁建模、风险评估、漏洞管理、事件响应与供应链安全并不是六个彼此独立的“工作包”，而是一条围绕“资产—威胁—风险—漏洞—事件—供应链”持续闭环的工程链路。理解它们之间的输入输出关系，比单独背诵术语定义更重要。本节先用一张关系图建立整体心智模型，再逐项拆解关键概念、方法流程与常见误区。
一、核心术语的定义与边界
资产管理是CSMS的起点。它要求组织识别车辆相关的所有资产，包括ECU、传感器、网关、总线、软件组件、数据资产、诊断接口、云平台接口以及外部依赖。资产清单不是静态表格，而应包含资产名称、版本、位置、接口、数据流、责任人、安全等级等属性。没有准确的资产清单，后续威胁建模和风险评估都会失去锚点。
威胁建模是在资产基础上，系统性地识别“谁可能通过什么路径、利用什么弱点、对资产造成什么损害”。常用方法包括STRIDE、攻击树、TARA（威胁分析与风险评估）等。威胁建模的输出是威胁场景清单，而不是直接的风险等级。
风险评估将威胁场景与资产价值、攻击可行性、影响范围结合，计算风险等级。ISO/SAE 21434中常用“影响×可能性”的矩阵方法，将风险划分为低、中、高、严重等层级，并决定是否需要新增安全控制措施。
漏洞管理关注已知弱点从发现到修复的全生命周期，包括漏洞扫描、CVE/CNVD跟踪、影响分析、补丁验证、修复记录和残余风险确认。漏洞是威胁建模的重要输入，也是事件响应的常见触发源。
事件响应是安全事件发生后的组织化动作，通常包括检测、分析、遏制、根除、恢复和复盘。在车辆场景中，事件响应还需考虑OTA回滚、车辆召回、远程禁用、取证数据保留等特殊手段。
供应链安全贯穿上述所有环节。它要求对供应商、开源组件、第三方库、云服务、工具链进行安全准入、SBOM管理、漏洞通报和合同约束。供应链风险往往不是“单点漏洞”，而是“上游污染导致下游批量受影响”。
二、方法流程：从资产到闭环的六步链路
- 资产识别与分级：建立车辆资产清单，标注安全等级和数据流。
- 威胁建模：针对高等级资产，使用STRIDE或攻击树识别威胁场景。
- 风险评估：对威胁场景进行影响与可能性评分，形成风险矩阵。
- 漏洞管理：将风险项映射到已知漏洞、组件版本和补丁状态。
- 事件响应：当漏洞被利用或出现异常时，启动响应流程并保留证据。
- 供应链安全：将上述要求写入供应商合同，要求SBOM、漏洞通报和修复时限。
关键关系：资产是“对象”，威胁是“可能”，风险是“优先级”，漏洞是“已知弱点”，事件是“已发生”，供应链是“外部输入”。六者共同构成CSMS的持续改进闭环。
三、案例/场景：一个T-Box漏洞如何贯穿六个概念
假设某车型的T-Box（远程通信终端）使用了一个开源MQTT库。资产管理阶段，T-Box被标记为“高安全等级、对外通信、含第三方组件”。威胁建模阶段，识别出“攻击者通过MQTT未授权订阅获取车辆位置”的威胁场景。风险评估阶段，该场景影响为“隐私泄露+车辆追踪”，可能性为“中高”，风险等级为“高”。漏洞管理阶段，发现该MQTT库存在CVE-2023-XXXX，可导致认证绕过。事件响应阶段，若该漏洞被利用，需立即启动远程诊断、OTA修复、日志取证和用户通知。供应链安全阶段，则要求该开源库的维护方提供修复版本，并更新SBOM。
| 概念 | 核心问题 | 典型输出 | 与其他概念的关系 |
|---|---|---|---|
| 资产管理 | 我们有什么？ | 资产清单、数据流图 | 为威胁建模提供对象 |
| 威胁建模 | 可能怎么被攻击？ | 威胁场景、攻击路径 | 为风险评估提供输入 |
| 风险评估 | 风险有多高？ | 风险矩阵、处置优先级 | 决定漏洞管理和控制措施 |
| 漏洞管理 | 已知弱点在哪？ | 漏洞台账、补丁状态 | 触发事件响应和供应链通报 |
| 事件响应 | 已经发生了什么？ | 事件报告、取证记录 | 反馈至资产和威胁库 |
| 供应链安全 | 外部依赖是否可信？ | SBOM、供应商安全协议 | 贯穿所有环节的外部约束 |
四、误区与复盘
常见误区一：把资产管理做成“Excel清单”。资产清单必须与数据流、接口、版本和责任人绑定，否则无法支撑威胁建模。
常见误区二：威胁建模只做一次。车辆OTA、新供应商、新功能上线都会改变攻击面，威胁建模必须迭代。
常见误区三：漏洞管理只盯CVE。车辆场景中，配置错误、权限过大、调试接口未关闭往往比CVE更危险。
常见误区四：事件响应只做技术处置。合规通知、用户沟通、监管报告、法律取证同样是事件响应的一部分。
常见误区五：供应链安全只签合同。没有SBOM、没有漏洞通报机制、没有修复时限的合同，只是纸面安全。
复盘时，建议用“资产—威胁—风险—漏洞—事件—供应链”六列台账，逐项检查每个高风险资产是否都有对应的威胁场景、风险评级、漏洞跟踪、响应预案和供应商约束。只有六列全部闭环，CSMS才算真正落地。
CSMS 闭环检查清单（示例）
[ ] 资产清单是否包含版本、接口、数据流、责任人？
[ ] 高安全等级资产是否完成威胁建模？
[ ] 威胁场景是否完成影响×可能性评分？
[ ] 高风险项是否映射到漏洞台账或控制措施？
[ ] 漏洞修复是否有验证记录和残余风险确认？
[ ] 事件响应预案是否覆盖OTA回滚、取证、通知？
[ ] 供应商是否提供SBOM并承诺漏洞通报时限？
[ ] 上述结果是否反馈更新资产清单和威胁库？总结来看，CSMS的核心概念不是孤立术语，而是一条从“识别资产”到“约束供应链”的工程链路。资产管理提供对象，威胁建模提供可能，风险评估提供优先级，漏洞管理提供已知弱点，事件响应提供实战反馈，供应链安全提供外部约束。六者相互输入、相互验证，最终形成可持续改进的安全闭环。