网络安全保证案例是连接 TARA、控制与测试到可辩护 Claim 的叙事。CAE（Claims-Arguments-Evidence）与 GSN（Goal Structuring Notation）是两种主流记法。
汽车网络安全团队会产出大量证据：TARA、架构模型、网络安全目标、需求、测试报告、渗透测试发现、SBOM、漏洞处置决定、供应商声明、软件更新记录与事件报告。然而，再大的证据集合也不会自动解释为何某辆车、某个 ECU 或某个软件平台是充分安全的。
做出这一解释，就是汽车网络安全保证案例的目的。
一个保证案例把三件事连在一起：关于受定义系统安全性的主张（Claim）；解释为何该主张合理的论证（Argument）；以及支撑论证每一步的证据（Evidence）。它还记录假设、运行条件、残余风险、置信度，以及"已证明事项"的边界。
这远不止是漂亮的合规报告。设计良好的保证案例会成为一种可复用的工程结构。Tier-2 供应商可提供组件子案例；Tier-1 可结合集成证据；OEM 可在不重做每一份供应商评估的前提下组装整车级论证。当软件、架构、漏洞或运行条件变化时，受影响的 Claim 可被识别并重新评估。
本指南说明如何构建这一运行模式，而不重复一份通用的 ISO/SAE 21434 实施指南或审计清单。聚焦于把零散的工作产物变成可辩护、可维护的网络安全论证所需的推理结构。
什么是汽车网络安全保证案例？
汽车网络安全保证案例是一种结构化、证据支撑的论证，论证某车辆 item、组件、功能或系统在定义上下文中达到可接受的网络安全水平。
一个简单的例子可以从这个顶层 Claim 开始：
在受支持的整个生命周期内，远程信息平台已得到充分保护，防止未授权远程控制。
该 Claim 过于宽泛，无法被单独接受。Argument 必须把它分解为更小的 Claim，例如：
- 外部可达接口被识别并加以保护。
- 设备与后端身份经过认证。
- 特权命令被授权且受到约束。
- 软件完整性从构建到安装受到保护。
- 安全控制已在代表性环境中得到验证。
- 漏洞与现场事件得到监测与处置。
- 残余风险已被识别、批准，并受明示假设的约束。
每个子 Claim 再由 Evidence 支撑。Evidence 可能包括架构基线、接口清单、威胁分析、安全需求、实现记录、测试结果、签名的发布清单、渗透测试报告、漏洞记录与监测程序。
案例还应说明其适用范围。脱离边界的"安全"毫无意义。可辩护的案例会标明所适用的确切产品、软硬件版本、变体、供应商、运行条件、支持周期、部署环境与排除项。
Evidence 不等于 Argument
许多组织把一文件夹的工作产物称作"网络安全案例"。文件夹也许齐全，但评审人仍需自己推断各部分如何拼接。
假设一份渗透测试报告显示某诊断接口没有可利用问题。该报告是 Evidence，但它本身并不证明该接口已得到充分保护。Argument 必须建立：
- 为何该接口对顶层 Claim 至关重要。
- 测试覆盖了哪些威胁与攻击路径。
- 测试针对的是哪些配置与版本。
- 测试方法是否适合预期攻击者。
- 哪些控制被实际触发。
- 还有哪些局限或未测条件。
- 结果在后续变更后是否仍然有效。
缺少这种推理，证据可能技术上很出色却与 Claim 无关。
反向问题也会出现。报告可能有强叙事陈述但缺乏强证明。"安全启动可阻止未授权软件"只是一个 Argument 片段，不是 Evidence。支撑性 Evidence 可包括启动链设计、信任锚预置、签名校验测试结果、负面测试、密钥管理控制以及目标产品基线的发布记录。
成熟的保证案例会把三者明确区分：Claim 说明所相信的事，Argument 解释为何如此，Evidence 展示已观察到或已实现的内容。
核心构件
Claims（主张）
Claim 是关于安全性、流程或证据质量的清晰、可检验陈述。它应足够具体，使评审人能够判断它是否得到支持。
有用的 Claim 模式包括：
- 某个被定义资产针对某个被定义威胁类被保护。
- 某项风险已降至组织接受阈值以下。
- 某项控制已在每个适用变体中实施。
- 某项需求已由当前证据验证。
- 某供应商组件在记录的假设下满足规定的安全属性。
- 量产后流程能够检测并响应相关漏洞。
避免绝对化 Claim，比如"该车不可被黑"。保证是上下文相关且基于证据的，而非零风险保证。
Arguments（论证）
Argument 把 Claim 在逻辑上连接起来。常见策略对顶层 Claim 进行分解：
- 按架构：整车、域、ECU、软件单元、接口。
- 按生命周期：概念、开发、生产、运行、维护、退役。
- 按威胁：欺骗、篡改、特权滥用、拒绝服务、信息泄露。
- 按控制目标：预防、检测、遏制、恢复。
- 按供应商责任：OEM、Tier-1、Tier-2、云提供方、服务运营方。
- 按运行状态或变体：制造、维修车间、客户使用、降级模式、区域配置。
选定的分解方式应匹配风险与证据的实际管理方式。漂亮但与工程归属不挂钩的图最终会失效。
Evidence（证据）
Evidence 应可识别、可归属、版本化，并与所支撑的 Claim 相关联。典型 Evidence 包括：
- Item 定义与架构基线。
- 资产、损害场景、威胁、攻击路径与风险记录。
- 网络安全目标、需求、控制与实现声明。
- 设计评审与代码分析结果。
- MIL、SIL、HIL、整车、模糊测试与渗透测试证据。
- SBOM、VEX 声明、漏洞记录与修复决策。
- 安全构建、签名、发布与软件更新记录。
- 供应商证书、评估报告与使用假设。
- 事件响应演练与量产后监测证据。
- 审计日志、批准、偏差与残余风险接受。
证据质量比文件数量更重要。缺乏产品版本、配置、日期、所有者、方法或预期结果的结果可能难以依赖。
上下文与假设
每个 Claim 都依赖上下文。例如：
- HSM 由 OEM 控制的密钥进行预置。
- 调试接口在量产中被禁用。
- 后端服务对特权用户强制多因素认证。
- 车辆运行在规定的环境或网络条件下。
- 供应商补丁在不改变受保护接口的前提下被集成。
假设应可见且可检验。隐蔽的假设是保证失败的主要源头。当假设不再成立时，受影响的 Claim 应自动进入复审。
理由与残余风险
案例应解释为何特定 Argument 策略、测试深度或风险决策是可接受的；也应识别残余风险，而不是把它埋在另一份风险登记表里。
一份残余风险声明应说明：剩余暴露、受影响范围、补偿性控制、监测、决策负责人、批准日期，以及触发重新审视的条件。
从案例必须支持的决策开始
保证案例应为真实决策而建，而非作为抽象的文档练习。典型决策包括：
- 批准某 ECU 通过 OEM 项目门。
- 接受某供应商组件用于集成。
- 证明已具备型式认证准备度。
- 授权某次软件发布或 OTA 活动。
- 接受某项残余风险。
- 判断某漏洞是否影响已部署车队。
- 向评估方证明所要求的网络安全属性已实现并经过验证。
决策决定了所需的范围、受众、详尽程度与证据时效。
例如，采购决策可能高度依赖组件安全属性、开发流程证据、认证、使用假设与供应商支持承诺。发布决策需要确切配置、测试结果、未关闭的发现、已批准的偏差与部署范围。现场漏洞决策需要 SBOM 关联、可利用性上下文、攻击路径、控制、车队暴露面与修复证据。
试图用同一份静态报告应对全部这些决策，会得到要么不可读、要么过于泛化的论证。
在收集更多文档之前先搭好 Claim 架构
改进保证案例最快的方式，常常是"先停止收集证据，先把 Claim 结构设计出来"。
实用的自顶向下流程是：
- 定义 item 与决策边界。
- 用平实语言写一条顶层 Claim。
- 识别支撑该 Claim 所需的主要 Argument 策略。
- 把每个策略分解为可评审的子 Claim。
- 挂接现有 Evidence。
- 标记未支撑、部分支撑、陈旧或假设依赖型 Claim。
- 分配负责人与关闭动作。
这便构建出一个"证据需求模型"。组织无需要求团队"把什么都上传"，而是可以为每条未支撑 Claim 索取所需的精确证明。
一个远程信息案例可能采用六条顶层策略：
- 架构与攻击面已被理解。
- 安全风险已被识别并处置。
- 信任、访问与软件完整性控制已实施。
- 控制已针对代表性攻击路径得到验证。
- 供应商与运行依赖得到治理。
- 漏洞与事件在整个支持周期内得到管理。
每条策略可按风险与决策需要逐步展开。
跨供应链的模块化保证案例
汽车供应链让"单体保证案例"难以为继。Tier-2 供应商可能提供被多 ECU 与多车辆项目复用的安全元件、操作系统、通信栈、传感器或库。为每次集成重复同一份评估既浪费时间又制造不一致。
模块化模型把供应商的论证作为可组合到更大案例中的子案例。
一个组件子案例应包含：
- 评估目标及确切版本。
- 声明的安全属性。
- 所考虑的威胁与攻击者假设。
- 安全功能与边界。
- 评估与测试证据。
- 已知漏洞与残余风险。
- 所需的环境控制。
- 集成指南与禁止用途。
- 有效条件、支持周期与变更通知规则。
Tier-1 不会只把证书或报告附上，而是补充集成论证：证明组件在其受评条件下被使用、配置正确，并与所要求的周边控制相结合。
OEM 再补充整车级证据，覆盖跨域攻击路径、变体行为、供应商交互、诊断、后端服务、更新与量产后运行。
这种方式还能保护知识产权。供应商可暴露有边界的 Claim 与证据包，无需交出每个设计细节；接收方仍能得到足以评估适用性与集成风险的信息。
组件认证如何支撑案例
GlobalPlatform SESIP 等组件评估方案之所以相关，是因为它们强调定义安全目标、保证级别、配置文件、组合与复用。一个被认证的组件可为整车论证的一部分提供可信证据。
然而，认证并不能取代整车级 TARA 或集成保证。
证书可能表明组件已实现并被评估了所定义的安全功能。但它不自动证明：
- OEM 正确配置了这些功能。
- 所需密钥与身份被安全预置。
- 周边软件以安全方式调用这些功能。
- 使用假设得到满足。
- 集成未引入新的攻击路径。
- 实际部署的版本就是被评估的版本。
- 运行监测与更新流程持续有效。
把组件认证作为一个证据模块。把每个被认证属性映射到它所支撑的整车级 Claim，记录假设，并补充集成相关证据。这样可以复用而不夸大认证所证明的范围。
随着"网络安全保证级别"与"目标攻击可行性"等汽车工作的演进，组织可预期会有更结构化的讨论，把保证投入与风险匹配。实用原则已经有用：对失败可能造成更大影响、或攻击可行性要求更高置信度的 Claim，应施加更强的证据、独立性、测试深度与配置控制。
置信度：证据有多强？
二元的"已支撑/未支撑"状态往往过于粗糙。两个 Claim 可能都有证据，但其中一个由对生产基线的独立实验室测试支持，另一个仅依赖某相似变体的旧设计评审。
保证置信度模型可以考虑：
- 相关性：证据是否直接回答 Claim？
- 范围：是否覆盖实际产品、变体与配置？
- 严谨度：方法是否与攻击者与风险相称？
- 独立性：必要时证据是否独立生成或评审？
- 新鲜度：在变更与新漏洞之后是否仍然有效？
- 完整性：证据与来源是否可信？
- 完备性：是否遗漏重要条件或攻击路径？
- 可重复性：结果能否被复现或独立检视？
置信度不应变成掩盖工程判断的任意打分。采用清晰准则，并把每个评级链接到底层证据与局限。
把变更视作"保证影响事件"
在软件定义车辆中，静态保证案例会快速失效。一次变更可能只让一条分支失效，也可能动摇整个顶层 Claim。
应触发影响分析的事件包括：
- 架构、接口或信任边界变化。
- 硬件或软件版本变化。
- 新增供应商或子供应商组件。
- 安全控制配置变化。
- 测试证据失败或过期。
- 新漏洞或威胁情报。
- 使用假设变化。
- 新增运行环境或车辆变体。
- 事件、异常现场行为或召回发现。
- 支持终止或无可用修复。
保证模型应能识别哪些 Claim 依赖被变更实体。例如，加密库出现新漏洞时，可顺藤摸瓜到受影响组件、ECU、控制、测试、已部署变体、供应商 Claim 与顶层 Argument。团队便可只评审受影响分支，而非手工重开整个案例。
这正是"活的保证案例"与"里程碑时刻生成的报告"之间的差别。
设计证据接受准则
证据在被允许支撑 Claim 之前应通过既定质量关卡。可复用的接受清单应要求：
- 唯一证据标识。
- 产品与配置范围。
- 来源组织与负责人。
- 方法、工具与环境。
- 日期与有效期。
- 预期与实测结果。
- 原始产物或受保护来源引用。
- 评审与批准状态。
- 所关联的需求、控制、威胁、风险或 Claim。
- 局限与偏差。
- 必要时的完整性或签名信息。
供应商合同应规定这些字段与交付格式。"提供一份渗透测试报告"是不够的。协议应说明目标基线、覆盖预期、严重性处理、证据保留、修复工作流，以及变更后必须更新的内容。
常见保证案例失败模式
文档堆
交付了上百份文件，却没有可导航的论证。评审人不得不自行重构推理，成本与不一致性同时上升。
循环论证
Claim 由一条需求支撑，而需求被认为得到满足只是因为它存在。案例必须包含实现与验证证据，而不仅是规范。
认证过度延伸
把组件证书当作整车或整车 ECU 安全的证明，集成假设与跨组件行为被忽视。
失控的复用
把其他项目的证据直接拷贝过来，却未证明架构、配置、威胁上下文与假设等同。
陈旧证据
测试在两个 Release 之前通过；尽管发生了相关变更，Claim 在仪表板上仍然为绿。
隐形假设
论证依赖安全预置、后端控制、车间策略或操作员行为，但这些并未在案例中体现。
缺少负面测试的证据
只测试预期行为。案例缺少证据，证明未授权、畸形、重放、过期或失序的动作会被安全拒绝。
顶层 Claim 无人负责
各团队各管其工作产物，却没有人对"组合后的论证是否充分"负责。
12 周实施路线图
第 1–2 周：选定一个决策与一个 item
选择一个真实的项目门、发布或供应商接受决策。定义范围、受众、基线与顶层 Claim。
第 3–4 周：搭建 Claim 架构
把顶层 Claim 分解为策略与子 Claim。记录假设、上下文与残余风险决策。
第 5–6 周：映射现有证据
把当前 TARA、需求、控制、测试、SBOM、供应商、发布与运行产物链接进来。把每个 Claim 标记为：已支撑、部分、未支撑、陈旧或不适用。
第 7–8 周：关闭关键证据缺口
优先处理未支撑的高影响 Claim、失效假设、缺失的集成证据与陈旧测试结果。不要先去完善每个低风险分支。
第 9–10 周：建立供应商子案例模式
为一家组件供应商定义标准包，包含属性、证据、使用假设、版本范围与变更义务。检验 Tier-1 或 OEM 能否在不暴露多余知识产权的前提下组装。
第 11–12 周：进行独立评审
让一位未参与构建的评审人从顶层 Claim 起跳，往返于证据之间。记录问题、缺失链接、含糊推理与回答时长。把案例基线化并定义更新触发条件。
当决策者能够理解"Claim 为何被支撑、置信度在哪里薄弱、什么会推翻结论"时，试点便告成功。
保证案例质量指标
有用的指标包括：
- 顶层与关键子 Claim 中具备可接受证据的占比。
- 仅由间接或陈旧证据支撑的 Claim 数量。
- 证据与确切配置基线挂钩的占比。
- 未验证的使用假设数量。
- 把一个 Claim 追到其证据所需时长。
- 识别受变更或 CVE 影响 Claim 所需时长。
- 符合标准接受模式的供应商子案例占比。
- 有效组件子案例在不同项目间的复用率。
- 无指定决策负责人或复审日期的残余风险数。
- 支撑高关键性 Claim 的证据平均年龄。
- 需要在案例外手动搜索才能回答的评审问题数。
- 失败测试或事件自动重开受影响 Claim 的占比。
目标不是最大化 Claim 数量，而是让推理完整、可检视、保持时效，并与风险相称。
ThreatZ 如何支持一个"活"的保证案例
保证案例天然是一个互联数据问题。Claim 依赖风险；风险依赖资产、威胁、攻击路径与假设；控制实现需求；测试验证控制；供应商证据支撑组件属性；Release 定义配置；漏洞与事件可推翻先前结论。
ThreatZ 可在网络安全知识图谱中表示这些关系，使案例直接从当前工程与运行证据生成，而非另起一份文档。团队可识别未支撑 Claim、复用供应商子案例、双向追溯证据，并查看哪些论证分支受变更影响。
一个强有力的试点是一个 ECU 或平台，搭配清晰的采购或发布决策。建立顶层 Claim、导入现有证据、暴露未支撑分支，并证明供应商或组件变更可被追溯到需要复审的确切 Claim。
常见问题
网络安全案例与保证案例有何不同？
两者常被互换使用。"保证案例"强调显式的 Claims-Arguments-Evidence 结构。仅包含工作产物集合的网络安全案例可能满足文档惯例，但其推理弱于结构化保证案例。
ISO/SAE 21434 是否要求网络安全案例？
ISO/SAE 21434 把网络安全案例列为生命周期工作产物之一。实务上的质量问题在于：案例是呈现"由当前证据支撑的结构化论证"，还是仅"打包文档"。
供应商证书能替代 OEM 整车级证据吗？
不能。证书可支撑定义的组件 Claim，但集成方仍需证明配置正确、使用假设、周边控制、版本标识与整车级行为。
什么是模块化保证案例？
它是一种由具有显式接口与假设的可复用子案例组装而成的保证案例。一个 Tier-2 组件案例可支撑 Tier-1 系统案例，进而支撑 OEM 整车案例。
保证案例应多久更新一次？
只要发生可能改变 Claim、假设、证据有效性或残余风险的事件就更新。相关事件包括架构变化、发布、供应商变化、新漏洞、失败测试、事件与运行条件变化。
最佳的首选用例是什么？
选择一个证据零散但可用的产品决策，例如接受一个安全关键组件或批准一次 ECU 发布。当团队不必在会议中重构论证，就能从顶层 Claim 直接走到确切、版本化的证据时，价值就会显现。
权威参考
- ISO/SAE 21434:2021 - Road vehicles - Cybersecurity engineering
- ISO/PAS 5112:2022 - Guidelines for auditing automotive cybersecurity engineering
- Automotive ISAC - Constructive Cybersecurity Assurance Cases
- GlobalPlatform SESIP methodology and resources
- GlobalPlatform - Cybersecurity Vehicle Forum 2026