ISO/SAE 21434解读：从TARA到CSMS的车载网络安全落地指南

我在汽车行业摸爬滚打这些年，最明显的感受之一就是“安全”这个词的含义彻底变了。以前聊整车安全，大家想的是碰撞星级、制动距离、气囊标定；这几年再打开任何一场技术评审会的议题表，前排位置几乎都被车载网络安全和ISO/SAE 21434占据。原因不用多解释——车早已不是纯粹的机械产品，它是一部带轮子的联网终端，通过蓝牙、Wi-Fi、蜂窝网、USB口不断和外界交换数据。远程解锁车门、篡改固件升级包、干扰毫米波雷达的感知结果，这些以前只出现在安全攻防演练里的操作，如今已经真实地走进了产品需求文档。

这种变化最直接的后果是，所有参与整车研发的人，从整车厂工程师到Tier 1零部件供应商，再到做芯片和操作系统的上游厂商，都得换一种思路做开发。ISO/SAE 21434正是这套思路的公约数。这篇文章我想从自己的项目经验出发，把这个标准的来源、核心概念、落地做法，以及实际操作中容易踩的坑讲透。如果你刚接手车载网络安全相关工作，或者正在为车型项目做合规评估，这篇文章里的内容应该能帮你少走不少弯路。

1. 先说清楚：ISO/SAE 21434到底是什么

1.1 标准的来源与定位

ISO/SAE 21434的全称是Road vehicles — Cybersecurity engineering，由ISO和SAE International联合制定，2021年8月正式发布。它不是凭空冒出来的，某种程度上延续了ISO 26262功能安全标准建立的“基于生命周期安全管理”的范式，但把关注点从功能安全扩展到了网络安全。“Road vehicles”这个限定词决定了它的服务对象：整车、系统、部件，乃至整个汽车产业链的上下游环节，而不是某一个单独的软件模块或某个ECU。

标准的整体思路可以概括成一句话：用工程化的方式管理网络安全风险。它覆盖了车辆从概念、开发、生产、运维到退役的完整生命周期，每个阶段都有对应的工作产品和管理要求。概念阶段要想清楚会面对哪些威胁，开发阶段要把安全机制设计进去，生产阶段要保证产线状态和设计一致，运维阶段要持续监控漏洞、响应安全事件，最后在退役阶段还要处理敏感数据和密钥。

标准发布之前，行业里不是没有网络安全实践，但各家做法差异非常大。整车厂有自己的一套安全需求，Tier 1供应商有另一套测试清单，专业安全公司再给出第三套评估方案。大家各做各的，最后在整车集成阶段经常对不上账。这种事我遇到不止一次：供应商说“我们做了安全测试”，但拿出来的报告是功能测试，完全没有威胁场景覆盖；整车厂说“这个部件有安全要求”，但连CAL等级都没有定义。ISO/SAE 21434的意义就在于提供了一套统一的工作语言和工作产品框架，让整车厂和供应商能在同一个语境下讨论威胁、风险、安全等级和验收证据。

1.2 它想解决什么问题

如果只用一个词概括ISO/SAE 21434要解决的事，我会选“系统性”。标准的核心目标有三个，彼此关联。

第一个目标是把网络安全从“事后救火”变成“事前设计”。传统开发流程里，安全问题往往是在渗透测试或安全事故之后才暴露，然后打补丁、发OTA，团队疲于奔命。而21434要求项目在概念阶段就做威胁分析与风险评估，提前识别攻击面，把安全需求写进系统需求里，让安全机制在架构设计阶段就位。说得直白点，它逼着你在画系统架构图的时候，就得同时画攻击面分析图。

第二个目标是建立覆盖全生命周期的管理闭环。一台车的设计寿命是十年甚至更久，而漏洞是长期存在的现实，不是交付时清零就完事。标准要求的漏洞管理、事件响应、信息共享机制，就是确保车在路上跑的每一天都有明确的安全责任方在跟进，而不是车辆卖出去之后出现问题就没人管了。

第三个目标，也是落地时最关键的，是让产业链上下游能高效协同。一台车上有几百个ECU、几十家供应商，如果每家按自己的方式做安全，最后根本没法集成。标准里专门定义了网络安全接口协议、CAL分级、工作产品交付这些机制，目的就是让整车厂能把安全要求分解给供应商，供应商也能用对方认可的格式把证据交回来。

我见过不少团队一上来就想找“最优安全方案”，但说实话，标准给出的不是最优解，而是最低共识线。真正做得好的项目，都是先通过21434把管理框架和沟通机制搭起来，再在框架之上做技术增强。

1.3 常见误区：它不是产品技术规范

有个理解上的坑必须提前说清楚，否则后面读标准全文会非常痛苦：ISO/SAE 21434不是一本“产品技术规范”，更像一张“考纲”。

它不规定你具体用哪种防火墙、哪种加密算法、哪种入侵检测系统，也不规定密钥长度必须是多少、总线加密必须用哪套协议。它规定的是流程、职责、分析方法和必须留下的证据。具体用什么技术方案去满足要求，仍然留给工程师自己判断。这也是为什么不少安全背景的人初读21434时会觉得“虚”——里面没有一行代码，满满都是流程描述和工作产品要求。

这种设计的合理性在于，网络安全威胁变化太快，如果标准把技术方案写死，发布之日可能就已经过时。你今天规定AES-128是底线，明天可能就被证明不再安全。所以标准选择了一种更聪明的方式：不管用什么技术，你都必须通过TARA证明自己识别了相关威胁，通过需求管理证明自己设计了应对措施，通过测试验证证明措施有效。这种“管结果不管实现”的思路，给了工程团队相当大的灵活性，也对团队的能力提出了更高要求。

2. 拆开标准的核心：TARA、CAL、CSMS

2.1 TARA——一切风险评估的起点

TARA（Threat Analysis and Risk Assessment，威胁分析与风险评估）是整个21434方法论的基石。你在标准里会反复看到这个词，几乎所有后续工作都由它导出——安全目标怎么定、CAL怎么分、需求怎么配置、测试做到什么深度，都和TARA的结果直接挂钩。

我第一次主导TARA时，最大的误区是想把所有东西都分析一遍，结果文档越写越长，真正能指导设计的结论却没几条。后来才想明白，TARA的产出不是一本“风险百科全书”，而是一张“优先级清单”。它要回答的问题只有两个：哪些威胁值得认真应对？应该应对到什么程度？

实践中，TARA通常按下面这些步骤走。

第一步，定义评估对象。可以是一台整车、一个子系统，也可以是单个ECU或一段通信链路。评估对象的边界、外部接口、运行场景必须先画清楚，否则后面所有分析都是空中楼阁。我习惯在TARA开始前，先把系统架构图、数据流图和物理接口清单整理出来，让参与评审的所有人对讨论对象有共同理解。

第二步，资产识别。资产不只是硬件和软件模块，还包括数据本身：用户的隐私数据、ECU里的私钥、诊断协议、软件更新包、位置信息等等。攻击者真正盯上的是能带来价值的东西，资产清单决定了威胁分析的范围。

第三步，威胁场景分析。针对每个资产，结合攻击者能力、攻击路径、入口点，推演可能的威胁场景。比如攻击者通过车载信息娱乐系统的Wi-Fi入口进入车内网络，随后向网关发送伪造的诊断请求，进而控制制动系统。这个环节非常考验经验，最好由安全工程师和系统架构师一起做，单靠一边很容易漏场景。

第四步，影响评级。对每个威胁场景评估潜在影响，包括乘员安全影响、车辆功能影响、用户隐私影响、财务影响等多个维度。标准没有强制规定某种具体评分表，但常见做法是把影响严重程度和攻击可行性分别分成若干等级，再组合成风险等级矩阵。评估完成之后，还要把风险等级映射到一个可比较的尺度上。

第五步，处置决策。依据风险等级决定“接受、缓解、转移、避免”四种处置方式之一。可接受的风险要有明确的理由和审批流程；不可接受的，要导出对应的网络安全目标，进而转化为网络安全需求。

TARA做得好不好，直接决定后续工作量。我见过不少项目的TARA把风险等级算出来以后就束之高阁，需求阶段和它完全脱节——这种项目最后多半都会在验证和审核环节被挑战。我自己的习惯是，TARA报告里每一个高风险威胁场景，都必须能对应到至少一条网络安全需求；反过来，每一条网络安全需求，也都能回溯到具体的威胁场景。这样才能形成真正的证据链，任何审核人员询问某条需求的来源时，都能直接指向原始威胁分析。

2.2 CAL——给风险定级，给部件分类

CAL（Cybersecurity Assurance Level，网络安全保证等级）是21434里另一个经常让人困惑的概念。标准将CAL定义为衡量网络安全保证措施严格程度的尺度，但并没有规定固定的数值区间，也没有强制统一“CAL 1到CAL 4”的说法。实际项目中，CAL需要结合TARA的风险评估结果、资产重要程度、潜在影响范围来综合确定。

我习惯于把CAL理解成“对某个部件投入多大安全保证力度的承诺”。比如，一个负责车辆制动控制的域控制器，如果被远程控制，后果就是乘员安全问题，对应的CAL必然很高；而一个只负责显示娱乐信息的车机模块，即使被攻破，对车辆安全的影响也有限，CAL可以适当降低。CAL定得越高，意味着需要付出的工程成本越高——更严格的开发流程、更多的安全测试、更高强度的代码审计。

实际项目中，CAL更大的价值在供应商协作环节。整车厂向供应商发包时，会明确每个组件的CAL等级，供应商根据CAL决定开发活动的深度和需要交付的证据。这个概念有些类似功能安全里的ASIL，但两者不能直接画等号。ASIL针对的是系统性故障和随机硬件失效，CAL针对的是恶意威胁和攻击行为，虽然安全等级的外壳很像，内核完全不同。

供应商交付审核时最容易出问题的，就是CAL等级和实际交付质量不匹配。比如合同里写了CAL 3，但供应商只提交了功能测试报告，没有威胁分析文档，也没有渗透测试结果。这种情况不用等审核老师开口，项目内部就可以判定交付不合格。所以CAL一定要在合同阶段就写清楚，并且把每个等级对应的交付物清单列成合同附件，避免后面扯皮。

2.3 CSMS——组织层面的管理骨架

如果说TARA和CAL是项目层面的事，那CSMS（Cybersecurity Management System，网络安全管理体系）就是组织层面的事。这个概念在UNECE R155法规里被反复强调，因为监管机构审核车型网络安全时，前提条件就是整车厂必须有一个经过认证的CSMS体系。ISO/SAE 21434虽然没有把“CSMS”作为单独术语命名，但对组织管理的要求贯穿全篇，包括网络安全策略、治理结构、人员能力、供应商管理、事件响应机制、持续改进等，本质上就是在构建一套企业级的网络安全管理体系。

我参与过的CSMS建设，通常从三个层面展开。第一层是策略层，定义企业的网络安全方针、目标、组织架构和职责分工，明确谁对网络安全负责。第二层是过程层，建立覆盖全生命周期的标准流程：TARA怎么做、需求怎么管理、测试怎么做、漏洞怎么响应、供应商怎么管理，每个过程都要有明确的输入、输出、角色和KPI。第三层是支撑层，包括文档模板、工具链、培训体系、知识库，以及和供应商、外部研究机构之间的威胁情报共享机制。

很多团队一开始把CSMS理解成“写一套制度文件”，然后花钱请咨询公司堆了厚厚一摞手册，发邮件让全体员工学习，就宣布自己有了CSMS。这种做法的最大问题不是不合规，而是不可持续——一旦项目开始运行，实际做法和流程文件对不上，审核时依然被挑战。我的经验是先花时间把现状流程梳理一遍，在现有开发流程基础上逐项补齐网络安全活动，而不是另起炉灶搞一套全新的“安全流程”让大家双线作战。

3. 怎么落地：从公司层面到车型项目

3.1 公司层面部署CSMS的实际路径

如果公司还没有任何网络安全基础，我建议按“搭骨架、补细节、跑起来”三个阶段推进，而不是一上来就追求完美体系。

第一阶段，搭骨架。花一到两个月时间，把组织架构搭好，明确安全负责人和管理代表；建立基本的文档体系，包括网络安全策略、风险评估流程、漏洞响应流程、供应商评估流程；定义TARA、CAL、工作产品这些核心概念的公司级模板。骨架阶段可以不用做得很细，但底线是“有流程可循”。

第二阶段，补细节。把每个流程细化到可操作程度。比如风险评估流程，除了方法论描述外，还要有风险等级矩阵、典型威胁场景库和报告模板；漏洞响应流程，要定义漏洞发现后24小时、72小时、一周内分别做什么处置，由谁负责升级，和研发团队怎么联动。针对细节补充阶段，最好用一个正在开发的车型项目做“磨刀石”，边做边完善流程，这比纯粹写文件高效得多。

第三阶段，跑起来。让流程嵌入到真实的项目开发节奏中，建立评审机制、审计机制和持续改进机制。比如定期对已交付项目做安全档案抽查，检查TARA文档是否真正驱动了需求，渗透测试报告是否覆盖了高风险威胁场景，供应商交付物是否完整。这些审计结果反过来推动流程和模板的版本迭代。

这个过程中，我觉得最难的不是技术和流程，而是让其他部门真正愿意配合。网络安全要求会增加研发成本和交付周期，如果没有高层授权和跨部门协调机制，很容易变成安全团队自娱自乐。我的经验是把安全活动嵌入到项目开发的关键里程碑里，和设计评审、测试评审绑定，让它成为项目进度的组成部分，而不是额外附加的负担。

3.2 项目执行维度的关键步骤

标准定义的产品开发流程覆盖概念、开发、生产、运维、退役五个阶段，每个阶段都可以对应到明确的工作产品。我结合自己的项目经验，把最核心的几个关键步骤梳理出来。

概念阶段的核心工作是定义网络安全概念并执行TARA。这里说的网络安全概念不是一句话目标，而是包含系统边界、资产清单、运行场景、攻击面分析、威胁模型在内的完整上下文。只有把上下文定义清楚，TARA才有分析的基础。概念阶段结束后，应该输出网络安全目标，也就是对每个不可接受风险的缓解方向。比如“必须防止非授权人员通过外部接口向网关发送控制指令”，这就是一条典型的安全目标。

开发阶段的核心工作是需求分解与安全实现。安全目标要在系统设计阶段转化为系统级安全需求，再分配到硬件、软件、通信协议、密钥管理各个层面，最终落到具体ECU和零部件上。实现过程中要同步进行安全编码规范检查、代码静态分析、通信协议安全设计评审等工作。很多团队到这一步才意识到TARA的价值——需求分解时如果没有TARA作为输入，就会变成拍脑袋写需求，既覆盖不全，又缺乏充分依据。

验证阶段的核心工作包括两部分：一是确认安全需求被正确实现，二是验证缓解措施真正有效。前者靠测试用例和代码走查，后者靠安全测试，包括模糊测试、渗透测试、安全功能测试等。标准强调的安全验证确认，实际执行时要注意把测试范围直接锚定到TARA识别的威胁场景上，否则测试做得再多，依然存在盲区。

生产阶段的核心工作是保证量产产品与设计一致，包括产线上的安全配置校验、密钥注入流程审计、生产软件状态追踪等。别小看这个环节，我见过不止一个项目，开发阶段做了一整套安全设计，结果产线烧录时把安全启动功能给关了，测试也没查出来。生产环节的安全管控，往往是最容易被忽略但实际出问题最多的地方。

运维阶段的核心工作是漏洞管理、事件响应和持续监控。产品上市后，要通过漏洞情报渠道持续获取新发现的漏洞信息，评估影响，规划修复方案，协调OTA推送。这套机制能不能跑通，取决于组织建设阶段有没有提前搭好响应团队和升级流程。到了上市后再临时组队，大概率会手忙脚乱。

3.3 供应商对接：这件事最容易被卡住

零部件供应商在整车开发里的参与深度，几乎贯穿始终。供应商做不做安全、做到什么程度，直接影响整车能否通过审核。21434对供应链的要求相当严格，整车厂必须对供应商进行监督和指导，而不是简单地把安全需求包甩出去。

我的实践建议是，和供应商的合作要从商务阶段就把安全条款写进去，落实到SOW和RFQ文档里。至少包含三类内容：一是角色分工，比如谁负责组件级TARA，谁负责集成级TARA，威胁库怎么共享；二是交付物清单，比如组件安全规范、测试报告、漏洞响应计划、安全档案；三是等级要求，即每个组件对应的CAL等级，以及每个等级对应的最低工作产品要求。

另外，网络安全接口协议（Cybersecurity Interface Agreement，简称CIA）要把双方在安全交互方面的接口定义清楚。这个CIA和保密性/完整性/可用性的“CIA三元组”是两回事，定合同的时候别把两者搞混。CIA应覆盖需要传递哪些威胁情报、漏洞响应窗口要求、安全相关的审批权限、审计和紧急支援如何协作这几类关键内容。如果不想在合同里写那么细，最低限度也要在项目启动会上把双方的安全责任人、沟通机制、响应时限对齐，否则中途一旦出现漏洞，扯皮会非常耗时。

TARA的时机也值得注意。我见过不少项目是整车厂自己把系统级TARA做完，才把需求包发给供应商，结果供应商拿到的需求是基于设计初期的威胁判断，等供应商做完自己的组件级TARA时发现威胁严重程度完全不同，需求再改一轮，整个开发周期都被拖累。更好的做法是早期就把供应商拉进来做初步威胁分析，哪怕只是粗略的边界讨论，也能避免后面的大改。

4. 真正实操中遇到的坑与心得

4.1 “文档合规”空壳问题

实际项目里最常见的坑，是“为了满足标准而堆文档”。原因通常在于项目发布压力大、认证审核时间紧，团队就会不自觉地把重点从“做安全”转移到“凑文件”。比如TARA写了十几个威胁场景，但风险等级全是拍脑袋定的；安全需求提了几十条，但没有一条能从TARA里回溯出来；渗透测试报告打印了厚厚一摞，测试范围却没有覆盖到任何高价值目标。

这种做法的风险，短时间内审核通过时可能感觉不到，但一旦后续出现召回或安全事件，整个证据链不足以支撑责任界定和风险转移，问题就会成倍放大。我的建议是不追求文档的完美，但每条结论务必可追溯。如果资源不够，宁可减少分析的场景数量，也要保证每个场景的分析质量、结论和后续动作闭环。审核老师真正看的往往不是文档厚度，而是逻辑链是否完整。

比如说，TARA里写“攻击者通过蓝牙接口获取车机Root权限”这个场景的风险等级是高，那后续就必须有一条明确的网络安全需求来缓解它，比如“蓝牙服务必须运行在沙箱环境中，禁止以root权限运行”或者“车机固件必须启用安全启动和签名校验”。如果这条需求不存在，那这个高风险场景就等于没被处置，整个安全档案就存在明显缺口。

4.2 标准间协调：R155、ISO 26262、ISO 21434

现在的新车型项目，经常会同时面对UNECE R155、ISO 26262、ISO 21434三个体系的要求。三份文件各有侧重：R155是法规强制性要求，关注型式认证和监管合规；21434是工程方法论，关注如何开展网络安全的工程与管理；26262是功能安全标准，关注系统性故障和随机硬件失效。对项目团队来说，最头疼的是三个体系的术语、交付物、评审节点常常相互冲突。

我整理过它们的主要差异，放在这里供参考：

实际做法上，三个体系之间可以共享很多基础工程资产，比如同一个系统架构图、同一套需求管理平台、同一套测试基础设施。差距在于分析视角不同。只要团队里有一个负责人能把三套流程的输入输出梳理清楚，避免给研发团队增加重复劳动，项目就成功了一半。落到具体执行时，我一般建议以R155的认证节点为时间轴，用21434的方法论填充安全工程内容，把26262已有的流程模板沿用来管理安全活动，三者能最大程度复用。

功能安全和网络安全之间还有一些强关联的场景。比如两个标准都关注“可用性”，但出发点完全不同：功能安全考虑的是硬件随机失效导致功能不可用，网络安全考虑的是攻击者故意制造不可用状态，比如DoS攻击。如果团队只按功能安全的方法做网络安全，往往会漏掉攻击性这个核心变量。

4.3 团队能力和工具链建设

工具链建设方面，我不主张一步到位买一堆昂贵的安全平台。团队刚起步时，用一套需求管理工具加一份精心设计的TARA模板，就能支撑早期项目运转。等团队规模变大、项目数量多了，再逐步引入威胁建模平台、自动化模糊测试工具、渗透测试跟踪平台。关键不在工具本身，在于工具产生的结果能不能被复用到研发流程中。威胁建模的产物要能直接进入需求库，渗透测试发现的问题要能自动生成缺陷单，否则工具只是另一座数据孤岛。

人员能力问题上，最大的瓶颈不是“会不会写代码”，而是“有没有攻击者思维”。安全工程师必须能站在攻击者角度想问题：这个ECU从哪些入口能碰得到？拿到某种权限之后能继续横向移动到哪里？这些思考在TARA阶段最见功底。团队组建时，我建议至少保证每个项目有一位有攻防背景的成员参与评审，哪怕是兼职，也比全程没有攻击视角要强得多。

最后，一定把“实际检验”纳入流程。不管文档里的安全目标写得多么完备，都不如落地一次真实的渗透或模糊测试来得可靠。我建议每个项目在验证阶段安排至少两轮安全测试：一轮在功能冻结前找实现层面的漏洞，一轮在量产前跑完整攻击链，确保前一轮的修复没有引入新的回归问题。

5. 一些值得长期坚持的做法

写到这里，前面该讲的方法和坑都讲得差不多了。最后我想分享几个自己一直坚持的日常做法，比起标准条款，这些更贴近实际操作中的体感。

5.1 把TARA当成活文档

不要做完一次TARA就归档。项目每发生一次重大变更，比如换了一个通信协议、加了一个远程控制功能、换了一家供应商的T-Box，都要回到TARA重新评估相关威胁场景。很多事后被攻击的系统，隐患往往都来自开发中期的“小改动”，而当时的TARA文档已经变成历史文件。我把TARA当作项目健康度的一部分来衡量——每次重大设计评审时，都要求TARA文档有一个对应更新版本，否则设计评审不予通过。

5.2 安全档案从第一天就开始写

安全档案不是验收阶段临时拼凑的总结报告，而应该伴随项目成长。每完成一个安全活动、每关闭一个漏洞项、每通过一轮安全评审，就把证据补充进去。这样到测试和审核阶段，安全档案自然水到渠成，不需要突击整理，内容也经得起追问。安全档案的价值不仅是给审核老师看的，更是项目成员之间共享的“安全记忆”，避免人员变动后安全设计意图丢失。

5.3 测试用例一定从威胁场景反推

很多团队的安全测试用例是从功能测试用例改过来的，看起来覆盖了功能，实际根本没有针对威胁场景。正确做法是，每个TARA里的高风险威胁场景，都至少对应一个安全测试用例，验证攻击路径是否真的被阻断。这条如果能做到，安全测试的有效性会提升一大截。我做测试计划时，会专门做一张“威胁场景-测试用例”的追溯表，挂在需求管理平台上，随时可以查证覆盖度。

车载网络安全这条路，没有标准答案，也没有终点。ISO/SAE 21434给我们的是一套可靠的工作框架，但真正让一辆车安全起来的，还是每个工程师在日常项目里多问一句“如果我是攻击者，我会怎么打进来”。遇到新披露的攻击案例时，先去对照自己的TARA找有没有场景重叠；供应商会议上听到对方说“我们的产品很安全”时，不客气地请对方拿出CAL等级和测试报告来。这些看似很小的动作，长期积累下来的效果，远大于任何一份模板化的合规文档。希望我的这些经验，能帮还在标准门外的同行少踩几个坑。