我先联网查 ISO/SAE TR 8477 的发布信息和技术内容，再按你要求的固定格式撰写。
已找到官方标准页，我继续读细则，把验证和确认的边界与证据要求理清。
我已拿到标准目录和中文研究材料，接下来再确认发布信息与配套解读。
先说结论。2026 年 11 月 6 日，ISO 与 SAE 联合发布 ISO/SAE TR 8477:2026《道路车辆 网络安全验证与确认》，第一版、28 页，由 ISO/TC 22/SC 32 与 SAE TEVEES18A 共同制定，是一份非规范性的技术报告（TR），定位是给 ISO/SAE 21434 补上 “验证与确认（V&V）到底怎么做” 的空档。它最关键的一句话是：验证回答 “我们有没有把网络安全做对”，确认回答 “我们做的是不是那个该做的网络安全”。渗透测试只是它列出的 11 类方法之一，所以 “做了渗透测试” 不等于 “完成了 V&V”。更重要的变化在最后一章：TR 8477 把 V&V 报告单独立章，要求报告能追溯到网络安全目标、TARA 假设和网络安全声明，能支撑网络安全评估。也就是说，测试记录只有按这套结构写，才能变成研发证据，而不是一堆躺在共享盘里的 PDF。
一、先看清这份文件是什么、不是什么
| 项目 | 内容 |
|---|---|
| 标准编号 | ISO/SAE TR 8477:2026 |
| 名称 | Road vehicles — Cybersecurity verification and validation（道路车辆 网络安全验证与确认） |
| 版本 | 第一版（Edition 1），2026 年 11 月，英文 28 页 |
| 发布 | ISO 与 SAE International 联合发布，Release Date 2026-11-06 |
| 制定组织 | ISO/TC 22/SC 32 与 SAE TEVEES18A 车辆网络安全系统工程委员会 |
| 文件类型 | Technical Report（TR），非规范性技术文件 |
| 规范性引用 | ISO/SAE 21434（唯一规范性引用） |
| 定位 | 讲策略、方法选择、活动顺序、职责分配、报告，不规定也不推荐具体方法 |
一句话记住：它是 “怎么做” 的说明书，不是 “必须做” 的法规。不能拿它去做认证，但它会成为审核方判断你证据充分性的参照系。
二、验证和确认，差的不只是一个字
| 维度 | 验证（Verification） | 确认（Validation） |
|---|---|---|
| 回答的问题 | 架构和设计是否满足网络安全需求（are we building it right） | 条目在目标车辆语境中是否足够安全（are we building the right thing） |
| 对照对象 | 网络安全需求，可对应需求层级任意一层 | 网络安全目标、概念性网络安全需求、运行环境假设、网络安全声明 |
| 作用范围 | 需求、设计、实现、集成，逐层向下 | 集成到目标车辆后的接口、运行环境与威胁场景 |
| 典型方法 | 审查、分析、代码分析、功能测试、模糊测试、故障注入、密码测试 | 整车级渗透测试、目标实现性审查、TARA 结论复核 |
| 时间点 | 各层级随开发推进随时做 | 可从初步架构与初步 TARA 起步，随开发迭代更新，在 post-development 发布前收口 |
两者的方法可以是同一套，这也是最容易混的地方。TR 8477 明确说 “目标不同，方法可相同或相似”，所以别拿 “我们做了渗透测试” 去同时交验证和确认两份作业。
三、为什么渗透测试替代不了 V&V
- 它只是 11 个方法组里的一个。 TR 8477 第 6 章列了审查、分析、形式化方法、代码分析、功能测试、漏洞扫描、模糊测试、压力测试、故障注入、渗透测试、密码测试，并明确说这份清单不排斥清单外的方法。
- 它的有效性有前提。 文本里讲得很直白：渗透测试效果取决于时间长度和测试人员能力，开始前必须先定范围、定攻击者模型，测试要镜像这个能力假设，否则结论不可比。
- 它的适用场景有限。 如果攻击路径已经被识别、并且已有专用方法覆盖，就不需要再做渗透测试；渗透测试更适合探索新的威胁场景，核心价值是证明漏洞可利用。
- 它证明不了 “没漏”。 它证明的是 “这段时间、这群人、这个范围内没打穿”，而验证要证明的是需求被满足，确认要证明的是目标已实现、风险已被处理。
所以真正的差距不在测试本身，而在证据链：需求 — 设计 — 实现 — 集成 — 目标，每一环是否都有对应的、可判定的证据。
四、把 “测过” 变成 “研发证据” 的五步
第 1 步：从需求层级倒着列证据清单
| 层级 | 要证明什么 | 证据形态 |
|---|---|---|
| 网络安全目标 | 目标完整（覆盖所有相关威胁场景）且已实现 | 目标确认结论 + 整车级渗透测试 / 审查 |
| 概念性网络安全需求 | 从目标直接派生的需求被落实 | 概念审查记录、控制措施差距分析 |
| 网络安全需求与架构设计 | 设计满足分配下来的需求，没引入后门类弱点 | 设计评审、分析、形式化验证 |
| 实现与集成 | 代码与集成行为符合需求 | 代码分析、功能测试、模糊测试、故障注入 |
第 2 步：先写策略，再挑方法
TR 8477 第 5 章要求策略至少说清四件事：范围与接口、这次要确立什么、选了哪些方法、为什么选这些方法。理由可以来自网络安全保障等级、方法组合对 “未识别漏洞残留” 的最小化论证、上层架构已覆盖所以下层可省略、或组织内部与客户 / 供应商之间的可信流程。没有理由的方法清单，在评审时基本等于没写。
第 3 步：把 TARA 和假设挂上去
这是最容易漏、也最容易被问倒的一段。TR 8477 明确：如果 TARA 的风险评级依赖某个控制（比如安全启动）、依赖条目的某个属性、或依赖某个假设，V&V 就必须证明 —— 这个控制真的实现了、效果符合预期、假设成立。此外还要证明识别出的威胁场景集合是正确且完整的。
第 4 步：执行时就把 “可复现” 写进记录
一份证据能不能被判，执行阶段就决定了。至少守住：测试人员独立性（不能是开发本人）、工具与库的版本可查、样品状态可追、判定依据明确（CVSS 或 CWE）、问题项跟踪到关闭。
第 5 步：按第 8 章写报告，再做变更联动
报告要能追溯到策略与计划，而不是只贴测试输出；设计一变、发现一改，相关 V&V 工作产品要同步更新，否则证据立刻失效（第 4.7 条讲的就是这件事）。
五、一份 “能过审” 的 V&V 报告该有什么
| 字段 | 作用 | 缺了会怎样 |
|---|---|---|
| 条目 / 零部件标识与版本 | 明确证据对谁有效 | 换版即失效，无法复用 |
| 引用的策略与计划 | 证明 “按计划做的” | 结果无法与范围对齐 |
| 测试环境与拓扑 | 证明环境可信、干扰可控 | 无线 / 网络类结论不可信 |
| 范围与攻击者模型 | 界定结论边界 | 结论被过度外推 |
| 方法与工具（含版本） | 可复现的前提 | 无法复核 |
| 结果、偏差与结论 | 支撑判定 | 只有数据没有判断 |
| 与目标 / 需求 / 假设的映射 | 形成证据链 | 进不了网络安全评估 |
| 作者与审查者 | 独立性可查 | 客观性受质疑 |
六、OEM 与供应商怎么分工
- 按网络安全接口协议（CIA）切。 V&V 可以由客户、供应商或第三方执行，前提是协议里把信息交换写清楚，让各方都能履行自己的那一段。
- 策略可以依赖供应商证据。 针对某条攻击路径，客户可以采信供应商提供的证据，但客户要提供让供应商能产出这份证据的输入（攻击面假设、攻击路径、运行环境）。
- 整车级确认可以用零部件级证据收窄范围。 这是 TR 8477 给出的务实做法：整车确认复杂度太高，用零部件证据合理界定攻击面，再由整车厂补齐接口与场景层。
七、四个常见误区
- 把 TR 当强制标准写进合同。 它是技术报告，写进合同要转成双方约定的验收条款，否则无法判定符合与否。
- 用一份渗透测试报告交两份作业。 验证与确认目标不同，证据映射的层级也不同。
- 只做 “下游测试”，不做 “上游审查”。 安全启动这类控制后期极难改，必须在概念阶段就验证。
- 证据不随变更更新。 设计一改，旧报告就成了历史文档，不是证据。
结论： TR 8477 没有让测试变多，它让测试变得可判定。先把验证与确认的目标分开，再把每条证据挂到目标、需求和 TARA 假设上，最后按第 8 章写成能追溯的报告 —— 这套动作做完，“测过了” 才等于 “有证据”。
【相关 FAQ】
问题 1：ISO/SAE TR 8477 是强制标准吗，和 ISO/SAE 21434 是什么关系？
回答 1：ISO/SAE TR 8477 不是强制标准，它是 ISO 与 SAE 联合发布的技术报告（TR），2026 年 11 月发布、第一版 28 页，唯一规范性引用就是 ISO/SAE 21434；它的作用是把 21434 里没展开的汽车网络安全验证与确认（V&V）策略、方法、职责分配和报告要求讲清楚，属于补充而非替代。
问题 2：ISO/SAE TR 8477 里，验证和确认到底怎么区分？
回答 2：在 ISO/SAE TR 8477 的框架下，验证判断架构与设计是否满足网络安全需求，可在需求层级任意一层开展；确认判断条目集成到目标车辆后是否足够安全，对照的是网络安全目标、概念性网络安全需求、运行环境假设与网络安全声明，并需在 post-development 发布前收口。
问题 3：做了渗透测试，是不是就等于完成了 ISO/SAE TR 8477 要求的验证与确认？
回答 3：不等于。ISO/SAE TR 8477 把渗透测试列为 11 类方法组之一，它证明的是特定范围、特定攻击者能力下的可利用性；而汽车网络安全验证与确认还要覆盖需求一致性、TARA 所依赖控制是否真实有效、假设是否成立、威胁场景集是否完整，单靠渗透测试无法形成完整证据链。
问题 4：按 ISO/SAE TR 8477 写 V&V 报告，最少要包含哪些内容？
回答 4：按 ISO/SAE TR 8477 第 8 章，报告至少要能追溯到条目或零部件标识、所依据的策略与计划、测试环境、范围与攻击者模型、方法与工具版本、结果与偏差、结论，以及作者与审查者信息；这样产出的研发证据才能进入网络安全评估。
问题 5：供应商提供的测试报告，OEM 能直接当作 ISO/SAE TR 8477 的证据用吗？
回答 5：可以，但有条件。ISO/SAE TR 8477 允许 V&V 策略依赖供应商证据，前提是按网络安全接口协议完成信息交换，且 OEM 提供攻击面假设、攻击路径和运行环境等输入；否则供应商证据的范围与整车语境对不上，不能直接作为确认证据。
问题 6：设计变更之后，之前的 ISO/SAE TR 8477 验证与确认证据还有效吗？
回答 6：通常会失效或需要更新。ISO/SAE TR 8477 明确要求，当发现、设计变更或细化影响工作产品时，相关验证与确认工作产品必须同步更新以保持一致，否则原有研发证据无法再支撑网络安全评估。
问题 7：ISO/SAE TR 8477 对国内车型开发有什么实际影响？
回答 7：影响体现在证据准备方式上。国内已有 GB 44495—2024 等强制性标准，出口车型还要面对 UN R155 的 CSMS 与 VTA 要求；ISO/SAE TR 8477 提供的验证与确认策略、方法选择理由和报告结构，正好可以把分散的汽车网络安全测试整理成可判定、可追溯的研发证据。
【参考资料】
- [2026-11-09]（ISO/SAE TR 8477:2026 - Road vehicles — Cybersecurity verification and validation）ISO 官网
- [2026-11-07]（ISO/SAE TR 8477:2026 - Road Vehicle Cybersecurity V&V）iTeh Standards
- [2026-11-06]（ISO/SAE TR 8477:2026 Road vehicles — Cybersecurity verification and validation，Release Date 06-Nov-2026）iTeh Standards
- [2025-12-01]（道路车辆 网络安全验证和确认 研究报告）全国汽车标准化技术委员会
- [2021-09-01]（汽车信息安全领域首个 ISO 国际标准正式发布）全国汽车标准化技术委员会
【免责声明】
本文依据 ISO 官方页面、标准公开样本目录及全国汽车标准化技术委员会公开研究报告整理，标准条文以正式发布版本为准；文中对条款的理解属于技术解读，不构成合规认证、法律或采购建议。企业落地前应结合自身网络安全接口协议与适用法规另行确认。