企业官网建设流程全解析

简介：这是一份ISO/SAE 21434-2021《道路车辆－网络安全工程》中文版PDF，面向汽车电子电气系统开发、功能安全与网络安全相关工程师，以及需要落地整车及零部件网络安全管理体系的团队。标准系统定义了从组织级网络安全管理、项目依赖管理、概念与产品开发，到生产、运维、退役全生命周期的工程要求，并给出威胁分析与风险评估方法，可作为建立网络安全管理体系、开展风险识别与验证活动的直接参考。资源为单个PDF文件，大小约1.46MB，内容覆盖标准全文条款、附录及工作产品标识说明，便于随时查阅条款编号与对应输出物。已有3125人学习下载，适合用于企业标准解读、内部培训或研发流程建设，尤其适合正在向GB/T?40857等国内标准或UN R155法规要求过渡的团队对照使用。

1. 先分清 ISO 标准和 ISO 镜像：ISO/SAE 21434-2021 中文版到底在管什么

第一次拿到《ISO/SAE 21434-2021 中文版 道路车辆－网络安全工程.pdf》，不少工程师第一反应是把它当成又一个 ISO 镜像文件，像 windows10 镜像 iso 文件下载回来那样，双击解压或者用虚拟光驱加载。它不是。这份标准是 2021 年发布的全球首个专门针对道路车辆网络安全工程的国际标准，2022 年 7 月之后，UNECE R155/R156 把网络安全管理体系（CSMS）和软件更新管理体系（SUMS）变成整车和零部件出海的硬门槛，ISO/SAE 21434 是落地 R155 时被引用最多的工程方法。它解决的是“车辆在被攻击时如何系统性地识别风险、控制风险、证明风险受控”，而不是某个防火墙或入侵检测工具的选型。适合质量管理、功能安全、嵌入式开发、TARA 落地团队一起读，尤其适合已经有 ISO 26262 基础、正在做功能安全与网络安全体系融合的团队作为对照参考。

顺带提醒一句：这份 PDF 如果打不开，先检查阅读器对加密文档的支持，别拿去转格式或者用 iso 转换工具处理，它跟系统镜像完全是两回事。它也不是 ISO 9001 那种管理体系认证标准，而是工程过程标准，读法完全不同。

2. 把 TARA 做扎实：威胁分析与风险评估的落地方法与风险矩阵参数

2.1 从资产识别到威胁场景：TARA 工作坊的四个步骤

ISO/SAE 21434 整本标准里，TARA（Threat Analysis and Risk Assessment，威胁分析与风险评估）是绝对的核心方法，标准第 15 条专门规定了 TARA 的流程要求。可以这么理解：网络安全目标定多少、安全需求怎么写、验证做到什么深度、残余风险怎么评审，全部由 TARA 输出驱动。TARA 做虚了，后面所有东西都是空中楼阁。

TARA 常见的落地方式是组织跨部门工作坊，不是某个人对着 Excel 憋出来的。参与人至少包括系统架构师、软件负责人、功能安全工程师、测试工程师、产品经理，必要时拉上售后和数据合规。工作坊按四步走：

第一步是资产识别。这里的资产不光是 ECU 和总线报文，要覆盖四类：网络资产（网关、T-Box、域控制器、诊断接口）、数据资产（车主隐私、密钥证书、配置参数）、功能资产（远程控制、自动驾驶、OTA 更新）、供应链交付物（第三方组件、开源组件、诊断工具）。识别资产的目的是为后续“什么被攻击会造成什么后果”提供对象。

第二步是威胁场景分析。新车开发阶段没有现成攻击事件，常见做法是用 STRIDE 方法做系统层面的威胁建模：Spoofing（欺骗）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（信息泄露）、Denial of Service（拒绝服务）、Elevation of Privilege（权限提升）。逐个功能组件过一遍，输出威胁场景描述。这块最容易出的问题是把威胁场景写成“黑客攻击车辆”，没说清攻击路径和攻击入口，后面的评级就没法做。

第三步是影响评级，第四步是攻击可行性评级。两步的结果合成为风险值，再决定处置策略。具体参数在 2.2 写。

2.2 影响评级与攻击可行性评级：风险值是怎么算出来的

ISO/SAE 21434 的影响评级不能只拍一个笼统的“高/中/低”，它要求从四个维度分别打分：Safety（安全）、Financial（金融）、Operational（运营）、Privacy（隐私）。每个维度按 1 到 4 打分，等级定义建议在组织级模板里先固化下来，否则每个项目各打各的，审核时完全没法解释“为什么这个影响是 3 而不是 2”。

以某个远程诊断功能为例：攻击者通过车载以太网端口对 DoIP 发起非授权诊断请求，影响维度可以这样打：Safety 维度如果诊断操作可能干扰制动系统，评 3；Financial 维度造成远程锁车被解锁或车载应用被滥用，评 2；Operational 维度导致诊断服务中断或车辆功能降级，评 3；Privacy 维度车辆位置和驾驶数据泄露，评 2。最终影响等级取其中的最高分，也就是 3。

攻击可行性评级按标准里的 CAL（攻击可行性等级）来定，同样分 1 到 5，评估依据是攻击时间、所需专业知识、设备复杂度、样本接触机会。公开攻击工具在手、普通笔记本电脑加 OBD-II 线就能做的攻击路径，可行性直接评 4 甚至 5；需要拆解硬件、有专门实验室设备的，评 2 或 3。

风险值的计算是影响等级乘以攻击可行性等级：

# risk_calc.py # TARA 风险值简化映射：影响等级 1~4，攻击可行性等级 1~5 impact = 3 # 影响等级（四维度取最高） feasibility = 3 # 攻击可行性等级 CAL risk_value = impact * feasibility if risk_value >= 12: treatment = "avoid / reduce（先改架构再谈缓解）" elif risk_value >= 8: treatment = "reduce（必须落地安全措施）" elif risk_value >= 4: treatment = "monitor / transfer（监控或转移）" else: treatment = "accept（管理层书面接受）" print(f"risk_value={risk_value}, treatment={treatment}")

这段代码的逻辑说明：风险值不是简单的乘积，但要先靠乘积把项目拉到一个可对比的刻度上。4 乘 3 等于 12 和 3 乘 4 等于 12 在数值上相同，但前者是高影响低可行性，后者是低影响高可行性，处置优先级不一样。所以风险矩阵使用时要额外标注可行性大于等于 4 的条目，即使乘积不高也要重点复核，因为这类攻击容易复制、容易规模化。

风险矩阵的组织级默认建议是：风险值大于等于 8 必须进入降低措施，大于等于 12 的高风险条目需要在系统架构层面想办法避免或转移，比如把诊断端口物理隔离、把密钥放到 HSM 里而不是依赖软件混淆。整个矩阵和阈值建议覆盖所有项目，由网络安全负责人统一维护，不能每个项目自己定义一套。

2.3 用 Python 和 YAML 把 TARA 产物固化：最小落地模板

TARA 光靠工作坊讨论、PPT 汇报是不够的，最终要落成结构化文档，并且能在整个开发生命周期里被追溯和更新。很多团队一开始用 Word 表格，但版本一多就乱，审核时翻旧版本想不起来当时为什么这么评级。我一般建议用 YAML 做威胁场景和评级记录的载体，配合 Git 做版本管理。

下面是一个最小 YAML 模板，每个威胁场景一条记录：

# tara_threat_scenarios.yaml threat_scenarios: - id: TS-001 asset: "远程诊断会话（UDS over DoIP / ISO 13400）" security_goal: "防止未授权的诊断访问" threat_scenario: "攻击者通过车载以太网端口向 DoIP 发起非授权诊断请求，获取诊断会话控制权" attack_path: ["物理接入 OBD 口", "DoIP 端口扫描", "会话绕过", "诊断指令注入"] impact: safety: 3 financial: 2 operational: 3 privacy: 1 impact_level: 3 # 取四维最高 feasibility_level: 3 # CAL 攻击可行性等级 risk_value: 9 treatment: "reduce" measures: ["诊断会话增加 TLS 双向认证", "网关层按诊断服务白名单过滤"] verification: ["模糊测试", "渗透测试用例 TC-DIAG-007"] status: "open"

这个模板参数说明：attack_path 字段要写攻击链，原因是后续评审要能看出威胁场景不是凭空想出来的。impact_level 和 feasibility_level 是评级结论，risk_value 是乘积结果，treatment 是处置策略，measures 是对应的安全措施，verification 是验证手段，status 是跟踪状态。同一份 YAML 文件放在 Git 仓库里，每个里程碑打 tag，审核时能直接看到风险从 open 到 mitigated 的完整演变过程。

如果团队对 YAML 不熟，也可以用下面的目录结构先跑起来，每个目录放固定模板，比 YAML 门槛低：

# 建立 TARA 工作产物目录，建议直接进 Git 仓库 mkdir -p csms_v2/project_x/\ {01_assets,\ 02_threat_scenarios,\ 03_impact_rating,\ 04_feasibility_rating,\ 05_risk_decision,\ 06_security_goals,\ 07_security_concept,\ 08_verification}

目录说明：01 到 05 是 TARA 的输入和过程产物，06 是 TARA 输出的安全目标，07 是网络安全概念设计，08 是验证证据。每个目录里放 README 说明本目录证据的更新人和更新时间，这个习惯对审核接待很管用。

3. 从概念阶段到退役：四段式网络安全工程流程怎么嵌进现有开发体系

3.1 组织级网络安全管理与项目启动：先建哪些岗位和流程

ISO/SAE 21434 的结构可以拆成组织层和项目层两部分。组织层要求建立网络安全管理体系（CSMS），包括网络安全治理、网络安全方针、能力建设、工具链管理、信息共享、持续改进。项目层要求每个项目在启动时做网络安全计划，维护网络安全案例（Cybersecurity Case），并在整个生命周期里持续更新。

很多团队拿到标准后直接开始做 TARA，回头看审核时才发现组织层的证据完全没有。组织层至少要落三件事：任命网络安全负责人（不能是功能安全负责人兼任但什么都不管），建立网络安全评审委员会（负责风险和处置决策，不是技术团队自说自话），发布网络安全方针和 TARA 评级规范（明确影响等级、攻击可行性等级、风险值矩阵的定义）。这三样是审核员必查的。

项目启动阶段要做的是网络安全计划（Cybersecurity Plan），它回答四个问题：这个项目的网络安全范围是什么（哪些资产和功能纳入），用什么方法做 TARA，按什么节奏评审和更新，以及怎样与供应商做职责分配。项目级网络安全计划和 ISO 26262 的项目安全计划在结构上非常接近，团队里如果有功能安全工程师，可以直接让他们按类似模板搭建，但内容上要区分故障风险和攻击风险的差异。

3.2 概念阶段和产品开发阶段：网络安全概念、需求与验证闭环

概念阶段的输入是 TARA 风险处置决策，输出是网络安全目标（Cybersecurity Goals）和网络安全概念（Cybersecurity Concept）。网络安全目标通常是一条条不可妥协的属性，例如“车辆必须防止未授权诊断会话建立”“固件更新包必须防止回滚和篡改”。网络安全概念则描述实现这些目标的系统级方案，例如划分安全域、在网关配置访问控制策略、将密钥存储在 HSM 中。

概念阶段之后进入系统、硬件、软件层的开发。系统层要输出网络安全规范（Cybersecurity Specification），把安全目标分解为系统需求；硬件层要明确 HSM 能力与密钥存储方案；软件层要落实 Secure Boot、Secure Communication（比如 SecOC）、安全日志等功能。这个阶段最容易踩的坑是把安全需求散落在各模块文档里，没有一条从安全目标下来的追溯链，导致集成测试时根本不知道要验什么。

验证阶段是审查看得最重的地方，不是看写了多少条测试用例，而是看测试用例能否对应回安全需求。常见做法是双层验证：静态层面的代码扫描和软件组成分析（SCA），动态层面的模糊测试和渗透测试。模糊测试重点放诊断协议和 OTA 下载链路，UDS（ISO 14229）和 DoIP（ISO 13400）是重灾区，诊断报文解析模块基本都能测出问题，建议从开发早期就开始跑。ISO 15765 定义的 CAN 传输层协议在传统车载诊断里很常见，如果某个诊断安全措施只考虑 DoIP 不考虑 CAN 诊断，就容易被低级手段绕过。

另一个容易忽略的点是与 ISO 26262 的接口。功能安全关心系统在随机硬件失效和系统性失效下的行为，网络安全关心系统在恶意输入下的行为，但两者在危害分析上有交集。例如“攻击者通过总线注入报文造成非预期加速”这个威胁场景，既涉及网络安全的影响评级，也涉及功能安全的安全目标。常见做法是网络安全团队在影响评级时用功能安全的危害分析结果作为输入，避免两边各自分析、结论打架。SOC 架构里同时跑 Autosar 的 E2E 保护和 SecOC 时，要特别注意两种保护机制同时作用下的兼容性。

3.3 生产、运维与退役：漏洞管理、事件响应和 OTA 更新

ISO/SAE 21434 覆盖到退役阶段，国内团队最容易忽略的是运维阶段的漏洞管理。漏洞管理流程至少要定义：从哪些渠道收集漏洞情报（包括公开 CVE、供应商通报、售后反馈、入侵检测告警），如何做漏洞严重度评估和风险评估，多久响应、多久出修复计划，修复包如何验证发布、发布后如何跟踪覆盖率。

事件响应流程要走通，不能停留在制度文件上。当监测到或接到报告说某个车型存在可利用漏洞时，响应团队要能在规定时间内完成初步评估、风险定级、临时缓解措施、修复验证和通知车主。这里说一句实话：很多 OEM 的网络安全事件响应流程和传统售后质量问题的响应流程没有打通，安全问题往往从 4S 店反馈到研发已经是几周之后，网络安全事件的窗口期根本等不了这个节奏。

OTA 更新是运维阶段最频繁的安全活动。OTA 每次都涉及固件包签名、版本回滚保护、安装失败回退、更新日志留存，这些措施的验证证据要能随时调出来。软件更新本身还有专门的法规和标准要求（EU 的 R156 和相关的软件更新工程标准），ISO/SAE 21434 管的是更新过程中网络安全不受破坏，别把两者混成一套证据。

退役阶段常用做法是定义车辆报废或转售时的数据清除和密钥销毁流程，特别是新能源车退役后电池梯次利用、二手车转售时的车主数据擦除。这块在审核中占比不大，但真被问到时如果什么都没准备，会在整体评价上很减分，建议至少发布一个《退役数据清除规范》文件。

4. 五个避坑记录：中文版、TARA 和审核证据链上的翻车现场

4.1 坑一：把中文版标准当权威依据，条款引用对不上

现象：内部报告中引用的是中文版条款号，审核员拿英文原版逐条核对，发现引用编号对不上，或者中文翻译和官方意思有偏差，来回解释浪费大量时间。

原因：ISO/SAE 21434 官方英文版是唯一权威文本。市面上的中文版通常是机构或团队自行翻译，术语翻译不统一，例如把“Cybersecurity”译成“信息安全”或“网络安全”的都有，条款结构也可能因为排版问题产生偏移。

解决：中文版只用于内部培训和快速阅读理解，正式交付物和审核证据一律引用英文原版条款编号。建议先建立一份中英术语对照表，把 Cybersecurity Case、TARA、CAL、Cybersecurity Goal 这些核心术语的用法在公司内部统一，再让所有项目文档按这个对照表写。

4.2 坑二：TARA 做成一锤子买卖，文档写完就归档

现象：概念阶段做完 TARA，输出一份风险登记表，后续架构调整、增加新功能、供应商交付物变化都没有更新 TARA，到审核时拿出的风险分析和实际产品已经对不上了。

原因：团队把 TARA 当成了“评审用文档”而不是“持续跟踪工具”。实际开发中架构一直在变，攻击面也一直在变，不做增量的威胁再分析，风险登记表就是废纸。

解决：把 TARA 文档定义为项目级活文档，设置明确的触发更新条件。常见做法有三种：任何架构变更、新增外部接口、供应商交付物版本变化，都要在评审检查单里勾选“是否需要更新 TARA”；每个开发里程碑至少复核一次风险状态和验证进展；安全事件或漏洞情报进来后，判断是否影响现有风险结论。更新不要求全量重做，但变更记录要留痕。

4.3 坑三：影响等级和攻击可行性等级的阈值拍脑袋定

现象：每个项目组自己定义影响等级打分标准，同一类型事故在这个项目评 3、在另一个项目评 2，风险值矩阵的红黄绿分区也各不一样。审核员问“为什么这个风险算高风险”，回答是“项目组内讨论决定的”。

原因：组织层没有发布统一的评级规范，或者发布了但没有强制执行。ISO/SAE 21434 的要求是评级方法在组织层面保持一致性和可重复性，不是每个项目各自发挥。

解决：由网络安全负责人在组织层发布《TARA 评级规范》，把四个影响维度各等级的定义、攻击可行性等级评估因素、风险矩阵阈值、处置决策规则全部固化，并规定所有项目必须使用同一套参数。规则本身可以后续修订，但修订要留有版本记录，不允许项目私自偏离。

4.4 坑四：功能安全和网络安全各做各的，结论互相矛盾

现象：功能安全团队做危害分析时认为某个失效模式风险可接受，网络安全团队做 TARA 时对同一系统评定出高风险，两边措施冲突，例如功能安全要求冗余，网络安全要求隔离，最后可能因为互相投入资源拉扯导致安全措施都不到位。

原因：两个体系流程各自独立启动，团队之间缺乏接口。ISO/SAE 21434 和 ISO 26262 的工程对象和危害模型不同，但最终作用在同一套系统架构上，不可能完全隔离。

解决：在开发流程中建立两个接口点。第一个接口点是危害分析阶段，网络安全的影响评级直接引用功能安全危害分析中的严重度结论作为 Safety 维度输入；第二个接口点是架构设计阶段，安全团队参与功能安全架构评审，确保安全隔离方案和故障容错方案不冲突。两个体系各自的评审会上至少要有一个对方的代表参加，不需要全程参与，但关键节点要在场。

4.5 坑五：审核前临时补证据，把测试报告后补到验证记录里

现象：审核前两周发现某个安全需求的验证记录缺失，测试团队加班补签名、补时间戳，做出来的记录漏洞百出，审核员只要一核对测试环境的版本号或代码提交记录就露馅。

原因：开发过程中没有同步收集验证证据，把验证当成审核前的整理工作而不是开发活动本身。

解决：验证证据绑定到开发流程里做，不做突击。具体做法是：每条安全需求从创建时就指定验证策略和验证用例编号，测试执行后测试用例报告自动关联到需求条目，代码仓库的提交记录上写明对应的安全需求号。审核前要做的只是检查覆盖率缺口，而不是补做测试。如果发现确实有漏测项，老实标记为未验证并给出残余风险评估，比伪造记录安全得多，也体面得多。

5. 审核前的验证方法：差距分析、证据链追溯和一个活文档习惯

5.1 用自评表做差距分析：照着逐条打分，不靠感觉

在正式认证审核前做一次自评，把整个体系按 ISO/SAE 21434 的结构拉成一张检查表，逐条评估每项要求的当前状态。评估状态分四档：不适用、未开始、部分实施、已实施有证据。

这个自评表的价值是让团队拿到一个量化的差距清单，而不是“我们基本都做了”的感觉。每项自评为“部分实施”的要有明确的关闭日期，差距分析至少在公司内部网络安全评审会上过一遍，不要自己评完自己看。

5.2 证据链怎么串：从安全目标到验证报告的双向追溯表

审核的核心动作就是抽几条安全目标，顺着追溯链查下去，直到看到可执行的验证证据。这个追溯链缺一环就要解释半天，与其现场查，不如在建项之初就把追溯表建好。

追溯表不是审核前生成的，应该是开发过程中每条需求创建时就生成一行，验证完成后填结果。只在审核前做的大表经不起推敲，因为测试报告的时间戳和代码提交顺序对不上。

5.3 一个活文档习惯：用目录模板和提交规范把安全案例维护起来

最后分享一个个人习惯。每一个项目从立项起就建一套网络安全案例目录，所有 TARA 记录、安全概念、验证报告都按固定目录放好，并且用 Git 管起来。安全案例本身不要求是一个大文档，它更像一个证据包，目录结构固定下来，里面的内容持续更新。每次里程碑节点更新后打一个 tag，比如 v0.9-concept、v1.0-design-freeze、v1.1-soffreeze。审核时直接从 tag 上拉出当时的证据快照，不用翻半天文件夹找某个历史版本。

这个习惯在多次认证审核里帮我省了很多事。审核员要什么，直接打开对应目录，文件命名规范、版本清楚、配套追溯表在 README 里写明白。相比之下，那些把网络安全案例做成一个大 Word 文档、靠人工维护目录和页码的团队，每次更新都是一场折磨。

回到最初的问题：这份中文版 PDF 值不值得读、值不值得照着做？我的看法是，做出口汽车和零部件，ISO/SAE 21434 不是可选项，R155/R156 法规已经把它变成交付条件；只做国内市场，提前按这个标准搭流程也比将来被审核逼着补要便宜得多。中文版可以读，但落地时一定要对着英文原版核对术语和条款，正式交付物里不能出现翻译不一致的引用。从最小的 TARA 工作坊开始，把一个项目的安全案例跑通，再复制到其他项目，这套体系最难的从来不是标准本身，而是让安全活动真正跟着开发流程走，而不是躺在文档里。

希望帮到你。

本文还有配套的精品资源，点击获取