2015年，两个安全研究员在高速上通过Uconnect娱乐系统的漏洞，远程给一辆切诺基的刹车和转向下了指令，克莱斯勒被迫召回140万辆车。那是整个行业被扇的第一个耳光——之前大家觉得“车联网安全”只是IT部门的事，那件事之后，汽车网络安全从一个技术边缘话题，变成了决定车型能不能上市、企业会不会被罚款、品牌信誉会不会崩盘的生死线。

国内主机厂和Tier 1真正开始系统性折腾这件事，是在UNECE R155法规生效之后：2022年7月起，欧盟要求新车型上市必须持有网络安全管理系统（CSMS）认证；国内对应的强标《汽车整车信息安全技术要求》（GB 44495-2024）也落地了。而ISO 21434就是做这一切的“操作手册”。这篇文章我围绕自己这几年做ISO 21434落地的真实经历来写，不堆概念，只讲实操中踩过的坑和能直接抄走的步骤，适合正在搭安全体系的主机厂安全工程师、Tier 1的项目经理，以及刚转行想做车联网安全的朋友。

1. 先把ISO 21434的骨架摸清楚

1.1 从SAE J3061到ISO 21434：标准是怎么长出来的

ISO 21434的全称是Road vehicles — Cybersecurity engineering，2021年8月正式发布。它的前身是SAE J3061，2016年出来的第一版汽车网络安全指南。J3061当时只是一本“指导手册”，告诉你“你应该考虑安全”，但没有强制规定你具体怎么做、做到什么程度。ISO 21434不一样，它把网络安全管理拆成了“组织级”和“项目级”两层，每一层都有明确的活动要求，并且和V模型开发流程强绑定——这一点和功能安全标准ISO 26262的理念一致。

理解ISO 21434有一个关键点：它不是产品认证标准，不认证单个ECU或整车。它管的是“过程”和“组织能力”。这就好比考驾照，ISO 21434不保证你一定不会出事故，但要求你具备规范驾驶的能力、系安全带、看后视镜、按规则变道——以此大幅降低事故概率。R155的CSMS认证实际审的就是组织和流程，不审产品。很多公司第一次做认证时没搞明白这件事，把精力全砸在写“安全规格书”上，结果审核员最关心的反而是你们漏洞响应流程通没通、TARA改没改、供应商有没有签协议。

1.2 标准里的关键词，先建立统一话术

ISO 21434里反复出现几个缩写，团队如果没有统一口径，开会全是鸡同鸭讲。

• CSMS：Cybersecurity Management System，网络安全管理体系。组织层面的制度、流程、资源的总和，是R155审核的对象。
• TARA：Threat Analysis and Risk Assessment，威胁分析与风险评估。项目启动阶段的核心活动，用来识别哪些风险不可接受。
• Cybersecurity Case：网络安全案例。证明“系统达到了可接受的网络安全水平”的证据档案，贯穿全生命周期。
• Cybersecurity Assurance Level（CAL）：网络安全保证等级。类比ISO 26262的ASIL等级，用来表示对某项工作“信任程度”的要求等级，等级越高，要求越严格。
• Vulnerability Management：漏洞管理。量产阶段的持续跟踪、评估、响应机制。
• VSOC：Vehicle Security Operation Center，车辆安全运营中心。量产后的安全监控与事件响应平台。

还有一对容易混淆的词：Cybersecurity Goal（安全目标）和Cybersecurity Requirement（安全需求）。目标是“所要求的风险降低结果”，比如“即使在通信链路被监听的情况下，车辆制动指令不可被篡改或伪造”；需求是具体的技术约束，比如“制动控制消息必须使用SecOC进行认证，且密钥轮换周期不超过XXXX”。写TARA报告时经常有人把这两个混着写，没分清目标层和需求层，后面做安全测试时根本没法写测试用例。

1.3 标准管的是全生命周期，不是开发那一锤子

ISO 21434覆盖从概念、开发、生产、运维到退役的完整生命周期，为什么这样设计？因为车的生命周期长达10到15年，一个漏洞可能在量产之后才被发现，如果最初没有持续监控和响应机制，漏洞就永远悬在那里。所以标准在每个阶段都标注了“what to do”，并且特别强调了“持续改进”。在你做项目计划时，不要把网络安全活动压缩到开发阶段——后面我会详细讲量产阶段会遇到什么问题，那是很多团队从一开始就没预留资源和预算的。

2. 组织级网络安全管理体系：没有制度，工具全是摆设

2.1 CSMS到底要建哪些东西

我们当年做CSMS认证时，按照R155 Annex的七项要求梳理内部体系，发现最费时间的不是安全技术本身，而是把公司原本“项目驱动”的做事方式改成“流程驱动”。CSMS至少包含五个层面：

• 网络安全策略：高层签发的安全方针，明确目标、范围、责任。别小看这一页纸，没有它，你后面推行任何流程都会被“我们没有预算/没有人力”堵回来。高层的承诺是安全体系的第一资源。
• 流程与过程定义：包括TARA流程、安全需求管理流程、漏洞响应流程、供应商评估流程、事件响应流程。每条流程都要有Owner、有输入输出、有退出准则。
• 角色与职责：至少明确网络安全官（CSO）、项目安全经理（Cybersecurity Manager）、安全工程师、审计员的角色。很多公司一人身兼数职，不是不行，但职责界面要写清楚，否则出了事故没人负责。
• 资源与培训：定义岗位能力要求，建立培训计划。安全团队每年至少要有一轮针对ISO 21434更新的内训。
• 持续监控与审计：定期的内部审计和安全绩效评估。

建体系时最常犯的错误，是想一步到位搞一个“完美的”流程文档，结果写了几百页，员工根本不看。务实的做法是先按最小可行流程跑起来，跑通一个项目后复盘，再补充文档。流程是长出来的，不是写出来的。

2.2 安全文化落地：别把“红队演练”搞成形式主义

ISO 21434的引言里提到“网络安全文化（cybersecurity culture）”，很多人都觉得这是虚的。但我的经验是，安全文化的强弱决定了流程执行的真实程度。举个最简单的例子：很多公司要求所有ECU供应商提供TARA报告，结果供应商交上来一份模板化的、只改了个产品名的文档——这时候你是选择“收到即归档”，还是发回去打回重做？没有安全文化的公司，一线员工大概率会选择睁一只眼闭一只眼，因为他们只求度量子项做完了，不求质量。

我们当时做了三件事来落地安全文化：第一，每个季度组织一次内部的“安全红线演练”，模拟一次量产车辆被攻击后的应急响应，要求采购、研发、售后、法务都参与，把预案跑一遍；第二，在工程师绩效里加入“安全意识考核”权重，防止业务一忙就把安全丢弃；第三，在新员工入职培训中加入40分钟的汽车安全通识课，讲事故案例，讲为什么要做TARA——哪怕画图岗位的人，也要知道他一笔画错的CAN信号可能造成什么后果。这三件事成本不高，但坚持一年下来，团队对安全的态度从“应付差事”变成了“习惯动作”。

2.3 供应链管理：你把安全责任扔给谁了

整车厂和Tier 1的供应链动辄几百家供应商，ISO 21434对供应链管理没有一刀切的要求，而是强调基于风险的责任分配。核心工具就是Cybersecurity Interface Agreement（网络安全接口协议，CIA），在供应商合同中明确双方的安全职责、协作方式、交付物和验收标准。

实践中，我们向供应商提出的最低要求是四份交付物：TARA报告摘要、安全需求清单、安全测试报告、漏洞响应承诺。其中“漏洞响应承诺”最容易谈崩，因为供应商担心要无限期承担义务。我们的解决方案是约定一个可执行的框：量产后的前5年内供应商需在发现漏洞后X个工作日内响应并在Y个工作日内提交初步缓解方案，之后每年续订一次服务协议。这个模式比一次性约定“永久负责”更容易让供应商接受，也把ISO 21434的“全生命周期管理”落到了合同层面。

顺带说一句，供应商管理最大的坑不是谈判，而是“供应商不知道你买这个件用在哪里”。安全需求如果脱离系统上下文，供应商做TARA时根本无从下手。我们的做法是，在询价阶段就提供一份粗粒度的系统架构说明和安全上下文。供应商只有在知道“这个ECU最终会控制什么、通信链路是什么、防攻击目标是什么”的前提下，才能做出有意义的TARA。

3. 项目级网络安全活动：TARA是灵魂，需求是筋骨

3.1 手把手做一次TARA：从资产识别到风险决策

TARA是整个ISO 21434实操中最核心、也最容易做砸的环节。做砸的常见表现是：威胁场景列了一大堆，风险评估全是“中/高/低”拍脑袋，最终风险决策没有任何逻辑。这样做出来的TARA只有审计价值，没有工程价值。

我按实操顺序拆一遍我常用的做法，以“智能网联汽车的OTA远程升级系统”为例：

第一步：确定分析对象和假设。明确这次TARA是针对整车、系统还是单个组件，以及边界假设。比如OTA系统，边界包括云端服务器、车端T-Box、IVI、网关、ECU，假设云端服务器本身由云厂商按行业标准保护，不在本次分析范围内。边界不明，后面一定会扯皮。

第二步：识别资产（Assets）。资产是需要保护的“价值对象”，分三类：数据类（升级包、日志、用户隐私、密钥）、功能类（OTA升级功能、回滚机制、整车控制指令）、可用性类（车辆可用性、服务可用性）。对每个资产定义其网络安全属性——机密性、完整性、真实性、可用性，至少标注损害场景。

第三步：识别威胁场景（Threat Scenarios）。用STRIDE方法逐类拆解：Spoofing（冒充）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（信息泄露）、Denial of Service（拒绝服务）、Elevation of Privilege（权限提升）。对每个资产，逐一问“攻击者能不能通过这条路径伤害它”。比如资产是OTA升级包，威胁场景可以列出：

• 攻击者在升级包下载链路中执行中间人攻击，替换固件包（Tampering）。
• 攻击者伪造云端服务器，欺骗车端下载恶意升级包（Spoofing）。
• 攻击者破解签名算法，伪造合法签名固件（Spoofing + Tampering）。
• 攻击者发送大量无效升级请求，占用带宽，导致合法升级失败（DoS）。

第四步：评估影响等级（Impact）。影响不能只打“严重”两个字，要按安全属性分别评估。对汽车而言，最核心的影响维度是安全（Safety）、财务、隐私、运营。我一般用四档：严重（S4，可能导致人员伤亡）、主要（S3，可导致财产损失或大规模功能失效）、次要（S2，导致部分功能受到限制但可控）、可忽略（S1）。OTA升级包被篡改，影响等级至少S4，因为它可能导致车辆失控。

第五步：评估攻击可行性（Attack Feasibility）。这是TARA中最有技术含量的一步。ISO 21434参考了Common Criteria里的攻击潜力评估方法，考察五个维度——时间、专业知识、对系统了解程度、机会窗口、设备资源。每个维度设一个等级，最后得出攻击可行性等级：极低、低、中等、高、极高。比如，“攻击者需要在升级包分发链路中的某个节点植入恶意代码，且需要TLS会话劫持能力”——时间维度需要数周、专业知识需要专家级、了解程度需要受限、机会窗口需要中等（需要物理接触或提前植入）、设备资源需要专业设备。综合下来攻击可行性为“中等”。

第六步：计算风险值并决策。把影响和攻击可行性映射到风险矩阵。ISO 21434没有规定固定矩阵，但要求组织自定义矩阵并说明理由。我常用5x5矩阵，风险值=影响×可行性，映射为不可接受、有条件接受、可接受。对不可接受的风险，必须制定安全目标来缓解。

这里有三个坑：一是很多人把“风险值”和“安全等级”混为一谈。安全等级（如CAL）是“为了达到某种信任程度你要投入多少验证力度”，不是风险值本身；二是威胁场景和攻击路径没区分开，威胁场景是“可能发生的不期望事件”，攻击路径是“具体怎么一步步打进来”。TARA阶段识别威胁场景就够了，过早陷入攻击路径细节会陷入无底洞；三是风险决策必须有人签字，不能是安全工程师自己拍了就算数。需要有一个跨部门的风险决策委员会，否则真出了问题，安全工程师一个人扛不住压力。

3.2 从TARA导出安全需求：让每条需求都能被验证

TARA结束后，不可接受的风险要转化为安全目标，再细化为安全需求。写安全需求有两件事我特别想强调。

第一，需求必须“可验证”。什么叫可验证？就是测试工程师拿到需求后，能写出明确的测试步骤来判断“通过”还是“失败”。比如“系统应检测OTA升级包是否完整且真实”——这就是不可验证的，因为“完整真实”没法量化。改成“系统应验证OTA升级包的ECDSA P-256签名，验签失败时应拒绝升级并记录事件日志”——这就是可验证的。让安全需求同时带“安全等级”（CAL），后续测试投入的程度跟着等级走。

第二，需求要可追踪。从安全目标到需求、到设计实现、到测试用例、到验证报告，全程要有一条追踪链。选个需求管理工具，别用Excel硬扛——几十个安全需求，几百个测试用例，Excel根本维护不过来。我们团队用的是JAMA和DOORS，小型项目Jira+Traceability插件也能凑合。追踪链是安全案例的核心支撑，审计时审核员最喜欢顺着追踪链问问题，链条断了就是不符合项。

3.3 开发阶段的“安全设计三件套”与验证活动

安全需求落到具体方案上，目前量产智能汽车最基础的三件套是安全启动（Secure Boot）、安全通信（SecOC）、安全存储（HSM/SHE）。

安全启动保证ECU只运行签名固件，从Boot ROM的根密钥逐级校验，防止固件被篡改后植入；安全通信（SecOC）给CAN/CAN-FD和以太网报文加认证码，防止伪造和篡改报文；安全密钥存储不能让私钥明文躺在Flash里，要用HSM或SHE等硬件安全模块，内部生成、内部使用、不可读出。

在验证环节，除了常规的设计评审，还要做三类活动：模糊测试（Fuzzing）、渗透测试（Penetration Test）、代码审计（Code Audit）。安全测试在测试计划里要预留足够时间，至少占该项目整体测试预算的15%以上，否则根本测不透。做渗透测试时一定要在台架或HIL环境里做，别直接在量产车上做——车辆电子架构耦合度高，一次失败的刷写可能带崩一整条链路，返工成本远超想象。

4. 量产之后的事：漏洞管理和VSOC才是持久战

4.1 建立漏洞管理的闭环

很多项目组在开发阶段打了个漂亮仗，然后量产交付后就“毕业了”。这是最危险的心态。车在消费者手里开10年，黑客也在持续研究它10年。ISO 21434的运维阶段要求组织建立漏洞管理流程，覆盖漏洞的接收、分析、评估、修复通知、发布缓解措施。

我见过的最大误区，是把漏洞处理希望寄托在“通过OTA直接修复”上。实际上很多漏洞不是刷个软件就能解决的，比如硬件密钥泄露需要换芯片，这种修复成本极高。所以漏洞评估不能只看CVSS，还要结合攻击路径和车辆上下文做一个“运营风险评估”。一个CVSS 9.8的IVI浏览器漏洞，如果车辆设计时已经做了网络分区隔离，浏览器域和车辆控制域不互通，那么实际的危害可能只是信息泄露，而不是车辆被控制——那它的优先级的级别就不用拔那么高；反之，一个CVSS 7.5的网关漏洞如果可以被远程利用，那可能就是需要紧急响应的最高优先级。要自己定义这个评估流程，不能套用通用的IT漏洞管理标准。

4.2 VSOC和事件响应的组织协同

VSOC不是买一套平台就完事。我们建VSOC时踩了不少坑，这里列几个具体心得。

第一，安全日志的设计在开发阶段就要做，不能等量产后再想。车载控制器资源有限，不可能把每个报文都上传云端。当时我们规定：登录失败、验签失败、诊断拒绝、异常刷写等“安全敏感事件”必须记录并上传；其他运行日志在本地滚动覆盖。日志记录的内容要在“够用”和“带宽成本”之间找平衡，一般认为每条日志几十到几百字节、每车每天几百KB量级在运营成本上是可接受的。

第二，事件响应流程要和售后打通。VSOC发现一个疑似攻击事件后，不能只让安全团队知道。需要同时通知售后部门准备诊断工具、通知法务评估通报义务、通知公关准备对外口径。如果这个流程没有事先理顺并做演练，真出事的时候就会乱成一锅粥。建议每半年做一次演习，把不同角色的响应时间当作考核指标。

第三，区分“威胁狩猎”和“事件响应”。VSOC每天会收到海量数据，不要一篇一律地上自动化检测规则。我们当时把工作分两层：常规自动化规则检测已经已知的异常模式，安全分析师每月做一次针对新威胁的手工狩猎，利用威胁情报更新查询。狩猎型安全分析师的编制容易被砍，但这一层能力是发现未知威胁的关键，不能省。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

我自己和身边同行反复踩过的坑，整理成一张速查表，供大家对照：

5.2 几条特别的实战经验

第一，安全需求一定要有“主人”。实际项目里信息安全团队写了安全需求，但开发团队觉得这些是“别人的需求”，优先级能拖就拖。我们用了一个办法：每个安全需求必须绑定一个负责开发的工程师和项目经理，在评审会上该工程师需要口头解释实现方案。绑定一个人的责任，效果远好于绑定一个“开发团队”的虚名。

第二，TARA不是一次性的。需求变了、架构变了、威胁情报更新了，都要重新跑TARA并记录变更。很多团队TARA做成了一次性PPT，制做完就束之高阁。我们后来把TARA做成“活文档”，每季度过一遍，每次架构评审时会议结尾加一项“TARA更新检查”。这也让安全团队能第一时间知道系统改动，不用事后补做安全评估。

第三，注意供应链的安全等级对齐。ISO 21434允许对上游交付物提出CAL要求，但很多团队不会用这个机制。比如一个A类安全等级高的组件，你可以要求供应商提供更强的安全开发证据、更多安全测试投入、甚至要求对方通过第三方安全评估。CAL如果只是写在纸面上的字母，没有转换成供应商工作量，那这个条目就白写了——审计时审核员一旦抽查，就是不符合项。

第四，关于安全团队“话语权”的问题。安全团队如果只做“提建议”的角色，流程就跑不动。我们在公司内部争取了两个授权：一是上市放行一票否决权——安全评审不通过，车型不能进入量产节点；二是风险接受必须升级到公司高层签字——一般风险安全团队内定，重大风险不接受项目经理直接拍板，必须上报CTO层。这两个授权定下来之后，安全流程的执行力立刻上了一个台阶。

6. 写在最后的个人体会

做了几个量产项目的ISO 21434落地之后，我最大的一个感受是：这个标准的难点从来不在“技术跳高”的难度，而在持之以恒的组织推动。你可以引入最好的HSM芯片，部署最强的VSOC平台，但如果TARA文档里写的风险没人管、安全需求没有一个工程师觉得是自己的职责、量产后的漏洞响应流程只是挂在墙上的PPT——那一切投入都会变成纸面上的“合规”，而不是真正的“安全”。

实际工作中，我越来越坚持一个“笨办法”：每年挑一个真实的安全事件，把当年的TARA、测试报告、漏洞响应记录翻出来对一遍，看如果事件发生在我们的系统上，我们能不能在应急响应时限内提得出有效的缓解方案。这件事做得多了，整个团队对ISO 21434的兴趣和理解，比任何培训都有效。标准不是用来束之高阁的，每一个条款背后都是一次次事故换来的教训。对齐标准，就是对齐那一个个早已用真金白银买过单的经验。

如果你正在推动公司过CSMS认证或建设安全体系，我最后送一条心得：先把涉及人和责任的东西定下来，再谈工具和技术。责任不清，后面所有漂亮的流程文档都会变成互相推诿的佐证。流程一旦跑顺，安全才能真正成为产品的一部分，而不是交作业式的负担。与各位共勉。