ISO TR 4804-2020全面指南：从技术报告解读到工程落地实践

简介：ISO/TR 4804-2020 是国际标准化组织发布的技术报告，聚焦道路车辆自动驾驶系统的安全与网络安全设计、验证及确认，面向汽车制造商、零部件供应商及功能安全、信息安全工程师。报告覆盖系统架构设计、故障检测与处理、冗余设计等安全工程方法，还给出通信协议加固、数据加密、访问控制及实时监测响应的网络安全措施；同时强调功能安全（ISO 26262）与信息安全（ISO/SAE 21434）的融合，并参考UN R155等法规，指导全生命周期风险管理与持续改进。验证部分涵盖模型在环（MIL）、软件在环（SIL）、硬件在环（HIL）、模拟仿真与实际道路测试，能够帮助读者建立从需求分析、测试执行到验收确认的完整流程概念。资源共1个PDF文件，压缩包约5.04MB，为ISO官方发布的2020年首版技术报告全文，可按章节精读或检索。已有1064人学习/下载，适合正在开展自动驾驶安全设计、网络安全管理或标准合规工作的工程师与研究人员参考。

1. ISO TR 4804-2020 是给谁看的：先分清「技术报告」和「标准」再决定买不买

不少从业者的硬盘里都躺过一份名为「ISO TR 4804-2020.pdf, 正版」的文件，要么是同事转来的，要么是从某个资料站捡来的。这份文件全称是 ISO/TR 4804:2020，是 ISO 关于道路车辆网络安全工程的一份技术报告，发布于 2020 年，核心内容是：如何在车辆电子电气系统的开发全生命周期里做网络安全工程，包括威胁分析与风险评估（TARA）、网络安全保障级别、验证确认方法，以及网络安全与功能安全如何协同设计。它适合功能安全工程师、网络安全工程师、内审员，以及正在为 ISO/SAE 21434 合规做准备的项目负责人读。但动手下载之前，先想清楚一件事：TR 是 Technical Report，是指导性文件，不是规范性标准。这一条决定了你该怎么引用它、怎么用它支撑工程决策。

2. 读懂 ISO TR 4804-2020 的安全模型：CAL、TARA 和生命周期活动

把这份 PDF 通读一遍并不难，难的是读完之后能在项目里复述出它的骨架。TR 4804 的正文不是技术方案，而是一套「在开发过程中如何做网络安全」的组织级方法论。它可以拆成四块内容：网络安全生命周期、威胁分析与风险评估（TARA）、网络安全保障级别（CAL），以及网络安全与功能安全的交互关系。下面按这三条线把模型讲透。

2.1 安全和网络安全为什么在汽车开发里不能分家：TR 4804 的立论基础

功能安全领域的人对 ISO 26262 很熟，它的基本假设是系统会遭遇随机硬件故障和系统性失效，故障是「非恶意的」。但汽车一旦联网，风险源就多了一个类别：一个有目的的攻击者。他可以反复试探、主动构造输入、利用多个漏洞组合攻击，这和随机故障的统计学模型完全不同。

TR 4804 的立论基础就在这里：网络安全攻击最终往往表现为安全危害。攻击者篡改制动扭矩请求，结果是车辆异常减速；攻击者重放固件包，结果是 ECU 进入不可用状态。反过来，功能安全设计如果不考虑网络安全，也可能被利用：安全机制设计了一个降级模式，正常情况下它能在故障时保护乘员，但攻击者可以故意触发降级条件，让车辆在高速路上跛行。这就是安全与网络安全交互的典型场景。

具体到工程上，这种交互有三种常被忽视的情况。第一种，网络安全事件触发安全机制：检测到报文被篡改后系统进入安全状态，但这个「安全状态」本身可以被攻击者当作开关来反复触发，造成拒绝服务。第二种，安全机制成为攻击目标：功能安全设计中的看门狗、安全控制器、冗余通道，如果没做网络安全防护，攻击者可以直接向它们发指令。第三种，诊断和运维通道被污染：远程诊断本是为了快速定位安全故障，但如果诊断会话能被未授权打开，攻击者就可以在安全机制的掩护下读取或篡改数据。

读 TR 4804 时，第一遍先抓住这个视角，而不是急着背流程。它的价值在于把「网络安全不是功能安全加一个补丁」这个观点用工程语言讲清楚了。如果你所在公司已经有功能安全流程但没有网络安全流程，导入 TR 4804 的正确第一步不是新建一套流程，而是把网络安全活动挂到现有 V 模型的对应节点上，让两类活动共享同一份系统定义和同一组评审会议。

2.2 网络安全保障级别（CAL）怎么理解：从 ASIL 到 4804，再到 21434 的差异

TR 4804 里有一个经常被引用、也经常被误用的概念：网络安全保障级别，缩写 CAL。它的思路和功能安全里的 ASIL 很像：不同系统遭受攻击后的后果严重度不同，所以应当投入的保障程度也不同。级别高的组件要做更细的分析、更严格的验证、更完整的文档。

这种分级思想其实有前身。SAE J3061:2016 是最早把「网络安全生命周期」引入汽车行业的报告，TR 4804 在它基础上把分级思路进一步工程化。但这里有一个关键区别必须记住：TR 4804 是技术报告，它介绍 CAL 是作为开展网络安全工程的一种方法，而不是作为强制要求；到了 ISO/SAE 21434:2021 发布时，标准委员会并没有把 CAL 作为规范性分级纳入，而是回到了「针对每个网络威胁场景逐项评估风险、逐项制定网络安全目标」的路子上。

下表是四者的对照，便于在项目汇报中快速说清：

这个差异在实际项目里影响很大。我见过有团队把 TR 4804 的 CAL 当成交付要求写进供应商协议，要求「所有 TARA 结果必须输出 CAL 等级」。审核时供应商反问「你要求 CAL II，依据是哪一条标准」，现场拿不出规范性条文，因为 TR 4804 从来不是规范性文件。正确用法是把 CAL 当内部资源分配工具：低级别组件做轻量 TARA，高级别组件做完整攻击路径分析和渗透验证，这个尺度由项目自己定，对外不必写成合规承诺。

2.3 TARA 的方法论：从威胁场景到风险矩阵，我建议这样读

TARA 是 Threat Analysis and Risk Assessment 的缩写，在汽车网络安全领域已经成了日常黑话。TR 4804 对 TARA 的处理方式比较务实：它给出了一组方法论建议，包括资产定义、威胁场景识别、影响评定、攻击路径分析、风险值判定和缓解措施选择，并提醒读者把 TARA 结果与 CAL 挂钩。

如果你是从零搭建 TARA 流程，我的建议是不要以 4804 为主干，而要以 ISO/SAE 21434 的 TARA 步骤为主线，用 4804 来补「安全与网络安全联合分析」的视角。原因是 21434 的 TARA 在工程可操作性上明显更强，它有明确的输入输出要求，对资产、威胁场景、影响评级的定义更适合直接落成记录表。

初读 4804 的 TARA 部分时，有一个很实际的方法：先跳过方法论比较类的内容，比如它对不同 TARA 方法的优缺点讨论，这类内容适合在方法论选型时再回头看。第一遍只需要抓住四个关键输出：资产清单、威胁场景列表、风险等级表、缓解措施列表。第二遍再对照附录里的分析示例，拿自己负责的一个 ECU 试做一次，就能理解威胁场景该怎么表达。

一个有效的威胁场景描述，不是「攻击者获得远程控制权」这种结论式写法，而是「攻击者利用诊断会话未认证的漏洞，通过 OTA 通道向网关发送伪造的配置指令」这种链路式写法。后者包含攻击入口、利用对象和造成的影响三个要素，评审时可以直接判断缓解措施是否对得上。这个表达习惯，读 4804 时不注意培养，后面做 21434 合规时一样要补。

3. 验证 ISO TR 4804-2020 正版 PDF：一份文件做五个动作再入库

手里已经有一份 PDF、但不确定是不是正版的人，这一章是给你准备的。正版不只是一个法律概念，它意味着文件内容完整、页面无缺漏、来源可溯。下面给出一套可操作的验证流程，分为外观检查、命令行检查、官网核对三步。

3.1 先看外观：封面、版权页和页脚水印能说明什么

ISO 官方出版的 PDF 是排版后的电子文件，不是扫描件，所以在 pdf 阅读器里打开后的第一印象就能筛掉一批问题文件。

正版文件的封面是深蓝色底，ISO 徽标清晰，文件编号 ISO/TR 4804:2020 在封面显著位置。版权页会明确标注 © ISO 2020，并声明 All rights reserved。正文页的页眉或页脚通常带有文档编号和页码，这个细节在扫描盗版文件里经常缺失——盗版扫描件往往只保留正文内容页，封面和版权页要么没有，要么模糊不清。

另一个辅助特征是水印。通过 ISO 官网或授权平台下载的文件，很多会带购买者信息水印，可能出现在页面边缘，这是授权痕迹的一种。要注意的是，这些外观特征只能说明文件「看起来像」正版，不能证明文件内部没有缺页或者内容没有被替换。要验证文件结构，得靠命令行工具。

3.2 用 pdfinfo、qpdf、mutool 验证文件结构和文字层

三个工具分别解决三类问题：元数据是否正常、PDF 对象结构是否完整、文件是否有可检索的文字层。它们都是 Linux/macOS 下的常见工具，Windows 用户可以用 WSL 或 Git Bash 安装。安装命令一般是这样：

# Debian/Ubuntu sudo apt install poppler-utils qpdf mupdf-tools

先看元数据和页面结构：

pdfinfo ISO_TR_4804_2020.pdf

输出里重点看四个字段。Title 字段：官方电子版通常带与文档相关的标准题名，如果这个字段是空的、乱码的，或者显示的是某个资料站的名字，说明文件被第三方软件重写过。Pages 字段和 Page size 字段：正常标准文件是统一页面尺寸，如果页面尺寸五花八门，大概率是翻拍照片拼成的扫描件，不是原始电子版。Producer 字段：记录的是生成 PDF 的软件，官方出版链路和桌面 pdf 编辑器生成的 Producer 明显不同。这里要说清楚，Producer 不是判断真伪的充分条件，只是线索，如果它和你采用的下载渠道对不上，就要多留个心眼。

再看结构完整性：

qpdf --check ISO_TR_4804_2020.pdf

qpdf 会检查 PDF 的对象结构、交叉引用表和文件尾部是否完整。如果输出大段警告或者提示需要修复，常见原因是下载过程被中断、文件被某个下载工具以「流式保存」截断，或者被某些在线转换服务处理过。这类文件后续出现缺页、打开报错、打印乱码的概率很高。遇到这种情况，不要尝试用 pdf 编辑器去修复，直接回到来源渠道重新获取文件更省时间。

最后验证文字层，这一步本质是一次 pdf 解析，用来判断文件是不是「假扫描件」：

mutool draw -F text -o tr4804_extract.txt ISO_TR_4804_2020.pdf grep -n -i "ISO/TR 4804\|cybersecurity\|road vehicles" tr4804_extract.txt | head -20

mutool 会把页面内容导出成纯文本。如果文件是纯扫描图像，导出的文本几乎是空的，或者全是乱码；正版电子版 PDF 则能抽出完整的文字层，并且能搜到文档里的关键术语。抽出来的文本还可以用来做内容抽查：搜索「attacker」「CAL」「TARA」等词，看出现频率是否正常。

注意一个边界：能复制文字、能搜索，只是正版的必要条件之一，不是充分条件。现在很多高质量盗版也带文字层。所以完整流程还必须做第三步：回到官方渠道核对文档信息。

3.3 回到 ISO 官网核对编号与题名：版本和授权状态一查便知

在 ISO 官网上搜索 ISO/TR 4804:2020，核对三件事。第一，编号格式是不是 ISO/TR 4804，中间必须带 TR 两个字母，Technical Report 的缩写；如果看到的是 ISO 4804 不带 TR，说明检索结果对应不上，或者那是一条不规范的二手描述。第二，年份是不是 2020；如果你手里的文件标注的是其他年份，说明版本需要进一步确认。第三，正式题名以 Road vehicles — Safety and cybersecurity 开头，和这份报告的内容定位一致；不少转售页面把它写成「道路车辆网络安全标准」，这个说法不算错，但容易让读者把它和 ISO/SAE 21434 混为一谈。

如果你所在公司接入了标准数据库，比如中国标准信息服务网或公司内部采购的标准化平台，从这些平台导出的文件同样带授权信息，效力和官网购买一致。内部使用完全没问题，但对外提供证据链时，最好保留官方源文件。

这里单独提醒一句：网络上传的很热的「免费 pdf 完整版」「pdf 免下载」资源，对 ISO 技术报告这类非公开出版物来说，基本可以默认有风险。技术报告不是免费公开文件，见到所谓完整免费版要警惕，至少做完上面三步验证再决定是否用于正式项目。

4. 把 TR 4804 用进研发流程：从一份 PDF 变成可评审的工作产物

拿到正版 PDF 只是第一步，真正考验人的是把这份建议性的技术报告变成研发流程里可评审的工作产物。TR 4804 的正文是叙述性的，不会直接给你一张可打印的检查表，所以需要自己动手把「建议」翻译成「交付物」。这一章给出的是经过多个项目验证的拆法。

4.1 按项目阶段拆交付物：一张可抄的网络安全活动表

把 TR 4804 的建议落到流程里，最直接的方法是按项目阶段拆交付物。下面这张表是通用做法，适合大多数 ECU 和域控制器项目：

这张表的用途是两个：一是做项目计划时直接用，把每条交付物填到项目计划和 WBS 里；二是做供应商管理时用来对齐范围，让对方知道你要求的是哪一层产出。

实际操作里有一个很顺手的技巧：在 TR 4804 的 PDF 里用阅读器的搜索功能定位关键词，比如 lifecycle、TARA、CAL、verification，把对应段落的编号抄到评审单的「依据」栏。这样每一份交付物都能反向追溯到技术报告的具体内容，评审时不用再翻整本 PDF，也方便以后往 21434 的条款上映射。

4.2 TARA 记录表字段设计：含影响等级和攻击可行性的打分口径

TARA 能不能做出质量，很大程度上取决于记录表设计得好不好。TR 4804 给的是方法论建议，不是具体表格模板，所以表格需要自己设计。下面这个字段结构是我实际项目里用得最顺的：

打分口径是最容易打架的地方。影响等级不要只看功能安全 Severity，还要把隐私泄露、法规罚款、品牌声誉算进去。比如一个 OTA 升级包被篡改，直接影响是车辆功能异常，间接影响是召回和监管处罚，两个方向都要打分。攻击可行性也不要只盯着技术门槛，还要看攻击者能不能物理接触设备：有物理接触和纯远程的攻击路径，可行性评分要拉开差距。

风险矩阵建议用 5×5，把结果分成高、中、低三档。中低风险可以走裁剪流程合并缓解措施，高风险必须逐项单独出网络安全需求，并指定责任人和验证周期。这个裁剪原则在 TR 4804 的语境里可以理解为：高风险组件对应高 CAL，要做完整活动；低风险组件做轻量处理，留一条记录说明理由即可。

4.3 把建议条款转成评审检查单：可直接放进设计评审模板

技术报告里的建议条款，落到日常设计评审里最好用的形态是检查单。与其每次翻 pdf 编辑器截图给评审组看，不如把关键条款整理成一份可勾选的清单，放进公司现有的设计评审模板里，作为网络安全专项页。下面这些条目是直接能用的：

1. item 定义是否包含外部接口、通信通道和后端服务？很多团队只列了 ECU 和传感器，漏了 OTA 服务器和手机 App，后两条恰恰是远程攻击的主入口。
2. TARA 是否覆盖全部三个安全属性？不少分析默认只看完整性，对机密性（如密钥、个人数据）和可用性（如拒绝服务）覆盖不足。
3. 网络安全验证活动是否进入了测试计划？如果只在验收阶段安排一次渗透测试，识别出的攻击路径就不可能在开发中闭环。
4. 高保障组件是否单独定义了网络安全需求并指派了责任人？没有责任人，需求就会在迭代中消失。
5. 是否存在安全与网络安全互斥的缓解措施？比如安全机制要求快速降级，网络安全机制要求验证数据完整性，两者可能互相等待。

每条检查项都可以在评审会上直接提问。这类问题的好处是切中要害，不用评审组成员事先读完全文。把它们沉淀到模板里以后，TR 4804 就不再是一份躺在共享盘里的 pdf 文件，而是真正融进了项目的质量门禁。

5. 常见问题与踩坑：盗版文件、版本混淆和把 TR 当标准的翻车现场

技术报告类文件在落地过程中踩的坑，大多不是技术问题，而是文件管理问题和引用方式问题。下面五条是我见过或者亲历过的真实案例，按「现象 → 原因 → 解决」讲清楚。

5.1 文件乱码或缺页：先查结构，不要直接换 pdf 阅读器

现象：下载的「ISO TR 4804-2020.pdf」在 pdf 阅读器里打开后，部分页面显示空白、乱码或者直接报错，还有人遇到目录点不动、复制出来的文字缺字。此时常见的反应是换一个 pdf 阅读器再试，结果问题依旧。

原因：文件本身结构已经损坏。多数情况是下载渠道不完整——网页断点续传、流式保存、在线转换服务截断，导致 PDF 对象结构缺失；少数情况是文件本来就是一个扫描件配了一个不完整的文字层，复制时缺字是常态。

解决：先用第 3 章的 qpdf --check 和 pdfinfo 排查，确认是结构问题还是内容问题。结构问题不要尝试用 pdf 编辑器修复，直接回到官方渠道重新下载；内容问题是扫描件缺文字层，按需补 OCR 或换官方电子版。处理完后用 mutool 抽一次文字层，确认缺页区域内容完整再入库。

5.2 拿 TR 当标准应付审核：技术报告不构成规范性依据

现象：项目组把 TR 4804 的章节内容整理成 PPT，作为网络安全工作的依据提交给客户审核，结果被客户和第三方审计追问「这是规范性要求吗」「哪一条是强制条款」，项目组当场解释不清。

原因：TR 是 Technical Report，性质是「提供信息」，ISO 对它的定位是辅助理解和指导实施，不是可认证的规范。客户要的是合规性证据链，依据必须是规范性标准。

解决：把 4804 定位成内部工程指南，把 ISO/SAE 21434 作为对外合规基线。对外材料里这样写是稳妥的：「依据 ISO/SAE 21434 建立网络安全管理体系，结合 ISO/TR 4804 的联合分析方法开展安全与网络安全协同设计」。这个表述既不夸大 TR 的地位，又把它的价值用在了合适的位置。

5.3 中文「官方版」陷阱：核对出版方而不是只看标题

现象：有人找到一份中文版文件，标题写着「道路车辆网络安全工程指南」，封面设计和排版很像官方出版物，于是当成官方中文版使用。后来核对发现，译文里有多处术语和原文对不上。

原因：ISO 的官方版本通常是英文和法文，技术报告类文件一般没有官方中文版。网上流传的中文版多数是第三方翻译，质量参差不齐；还有一部分是标注「GB/T 采标」的，但 TR 4804 是否对应某个采标版本，要以官方采标目录为准，不能凭标题猜测。

解决：内部学习用中文译文没问题，但对外提供证据链和技术依据时，一律以官方英文 PDF 为准。核对方式很简单：中文版封面如果找不到国际标准出版机构的标识、找不到翻译机构信息，就不要把它当成官方文件在正式场合引用。可以把中文版当作快速入门的辅助材料，正式评审时回到英文原文。

5.4 风险矩阵全红翻车：影响等级锚点要在会前对齐

现象：一次 TARA 评审会上，各领域代表把影响等级全部打 4 分或 5 分，攻击可行性也普遍打高，结果风险矩阵一片红，几乎每个威胁场景都是高风险。下一步没法做优先级排序，评审会变成了争吵会。

原因：团队没有在会前对齐影响等级的定义。功能安全背景的人把「影响等级」等同于「安全后果等级」，隐私背景的人把「影响等级」等同于「个人数据泄露规模」，两个口径混在一起，分数自然漂移。

解决：每次 TARA 会前花 10 分钟对齐锚点。常见做法是提前定义好 1-5 级的具体说法：比如 1 级是不影响车辆安全，2 级是影响非安全功能，3 级是需要驾驶员干预，4 级是可能导致车辆异常行为，5 级是可能导致严重安全事故。再叠加隐私和合规维度，每个级别给一个真实例子。这样打的分数才有横向可比性，评审效率会明显提高。

5.5 和 SAE J3061 混用：编号写全，简称会吃暗亏

现象：项目文档里引用资料时只写「根据 ISO 4804」，有时又混着写「J3061 里讲的 CAL」，导致审核方分不清这个项目到底参考的是新旧哪份文件。

原因：TR 4804 和 SAE J3061 内容高度相似，J3061 是 2016 年的技术报告，4804 是 2020 年的后续报告，方法论一脉相承。口头简称「ISO 4804」的时候，听起来像一个正式标准编号，实际上省略了 TR 两个字母，语义就变了。

解决：项目文档里第一次出现时必须写全称「ISO/TR 4804:2020」，后续用简称也要固定成「TR 4804」而不是「ISO 4804」，避免和潜在的正式标准编号混淆。引用 J3061 时单独写全称，并在参考文献里注明两者关系。这个习惯在过第三方审核时能省掉很多解释成本。

6. 从 ISO TR 4804 走向 ISO/SAE 21434：验证自己读没读懂的三个自测

如果你把前面的验证动作和落地方法都做完了，最后一步是确认自己是不是真的读懂了 TR 4804。三个自测题比任何读书笔记都管用，这里给出题目和参考答案，你可以自己先答一遍再看后面。

第一题：用一句话说清 TR 4804 和 ISO/SAE 21434 的关系。如果只能说出「一个是老版一个是新版」，说明还没吃透。合格的回答是：TR 4804 是技术报告，提供网络安全工程的方法指导，不具有规范性约束力；ISO/SAE 21434 是规范性国际标准，定义了网络安全工程的要求和审核口径。前者在后者的起草过程中提供了方法论铺垫，尤其体现在安全与网络安全联合分析、以及保障级别思路的讨论上，但 21434 最终没有把 CAL 作为强制分级。

第二题：给你一个带 OTA 升级功能的车载网关，能不能在半小时内起草一页 TARA 草稿。试展开：资产至少写网关固件、签名密钥、升级包、诊断接口四项；威胁场景至少写三条，包括攻击者伪造升级包注入、攻击者重放旧版固件实现降级、攻击者通过诊断接口篡改配置；每条威胁场景要给出影响等级、攻击可行性和对应的缓解措施。能不看模板独立写出来，说明 TARA 方法论已经成你自己的了；如果写不出来，回头再读一遍 TR 4804 里 TARA 输入输出部分，重点看威胁场景的描述格式。

第三题：列出两个 TR 4804 里提出、但 ISO/SAE 21434 里弱化或调整的概念。除了前面反复提到的 CAL 之外，还有「安全与网络安全联合风险管理」的思路。在 4804 的叙事里，功能安全和网络安全是同一个风险场景的两面，需要联合分析；21434 更务实地把网络安全风险作为独立域管理，再要求与功能安全活动通过接口协调。能答出「哪个弱化了、为什么弱化」，才说明你对比着读进去了，而不是只看了一本书的封面。

提示：这三个自测题的答案可以直接用在你给团队做的内部培训里，当作开场提问效果不错。

我自己做第一个车载网络安全项目时，就是把 TR 4804 当成了 21434 的替代品，带着整组人按技术报告的强度写交付物。审核老师问「你的 CAL 依据是哪个条款」时，我现场翻 pdf 翻了两分钟没找到对应段落，场面很尴尬。从那之后我养成了一个习惯：任何标准类 PDF 入库前，在封面笔记里写上文档类型（TR/TS/IS）、年份、获取渠道，再存档。TR 4804 这份文档是值得买的，但必须知道它在你流程里的位置。希望这些验证方法和落地清单能帮到你。

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