ISO 21434 审核中的可追溯性：让模糊测试真正算数

ISO/SAE 21434 并不只是要求你做到安全。它要求你向评估员证明这一点，而且要有证据。正是这一差别，让许多扎实的安全工作在审核中功亏一篑，而安全测试是其中最鲜明的例子。

标准要求测试，也要求书面记录

测试方面的要求足够清晰。Clause 10.4.2（集成与验证）要求你验证实现满足网络安全规范（[RQ-10-09]），[RC-10-12] 则建议进行组件测试，包括模糊测试和漏洞扫描，以尽量减少未识别的弱点。Clause 11（网络安全确认）明确提到渗透测试（[RQ-11-01]）。从 CAL 2 起，对通信接口进行模糊测试实际上已是默认预期。

但 21434 评估并不以你是否跑过模糊测试工具来打分。它看的是你的工作产品：验证报告、确认报告，以及最终论证你的对象已足够安全的网络安全案例，并在网络安全评估（Clause 6.4.9）中接受评判。评估员阅读的是论证以及支撑它的证据。一次没有写入该论证的模糊测试活动，和从未发生过没有区别。

一句话说清双向可追溯性

评估员反复索要的东西叫双向可追溯性：从每一条网络安全需求到验证它的测试之间有书面链接，从每一项测试也能回溯到对应的需求。

对安全测试而言，这意味着评估员可以从一个网络安全目标出发（“ECU 在未经认证的情况下不得接受诊断写入”），沿着它找到对应的网络安全需求，再找到检查该需求的测试，看到测试结果、测试日期，以及任何发现的后续处理。反过来也一样：挑出一项发现，就能追溯到它所威胁的需求。

大多数团队拿得出测试。能在评估当天拿出这条完整链路的，要少得多。

模糊测试的难点究竟在哪里

模糊测试在可追溯性上格外棘手，原因有三：

• 它天生是非确定性的。 一个无法复现的崩溃只是一则轶事，而不是证据。评估员不可能接受“三月份崩溃过一次”这样的说法。
• 它产出的是数量，而不是结构。 数百万次迭代和一堆日志，无法清晰地映射到一份简短的网络安全需求清单上。
• 它跑得晚，也跑得少。 审核前的一次性测试活动只能说明你那一周手上的软件，而不是你最终交付的软件，而且不带任何历史记录。

因此，评估员真正想问的关于模糊测试的问题不是“你做过模糊测试吗？”，而是：这项发现能复现吗？你第一次看到它是什么时候？它关联哪条需求？你对它做了什么？

可供审核的安全测试证据长什么样

无论你用什么工具，证据都必须包含五个要素：

1. 可复现性。 保存的种子或配置，使任何发现都能按需重放，你能做到，评估员也能做到。
2. 带日期的历史记录。 不是一张快照，而是贯穿 ECU 整个生命周期的测试内容与时间记录，让你能展示趋势，而不只是最终状态。
3. 与需求的关联。 每项发现都绑定到它影响的网络安全需求或工单，让双向追溯得以成立。
4. 有记录的风险接受。 当接受某项残余风险时，该决定及其理由被记录在案，并延续到下一个测试周期。
5. 可读的导出。 证据必须以评估员和你自己的跟踪系统都能使用的形式离开工具：归档用 PDF，工具链用 SARIF。

把这五点做对，一次模糊测试活动就不再只是一个日志文件，而成为一份工作产品。

AutoST 如何为此而生

这正是 21434 项目中 AutoST 被设计来承担的部分。

每一次运行都可复现：模糊测试种子会被保存并显示，因此崩溃可以被精确重放。每一次扫描都带有日期并被保留，因此 ECU 整个生命周期的历史是现成的，而不是事后重建的。每项发现都带有严重程度和具体的修复措施，Fix Plan 为每个任务提供状态和一个 ALM/PLM 引用字段，回溯到你的需求或工单的链接就存放在这里。风险接受和评论会跨越重测延续，因此已接受的残余风险始终有据可查，已修复的问题会显示为已解决。输出则是审核归档用的 PDF 和工具链用的 SARIF。

由于 AutoST 通过 API 运行并集成在 CI 中，测试成为 Clause 8.5 所指意义上的持续活动，而不是评估前的一场突击。评估员看到的是趋势和轨迹，而不是一次孤立的英雄式行动。

坦诚的边界

AutoST 产出测试证据并保持其可追溯。它不会替你编写 TARA，不会替你运行网络安全管理体系，也不会替你撰写网络安全案例。那些是流程和工程判断的工作。Zyberum 同样以咨询的形式承担这一侧的工作，团队持有 SAE 与 TÜV SÜD 的 ISO/SAE 21434 汽车网络安全认证，并已带领 Tier 1、Tier 2 和 OEM 项目走完了同样的路。可应要求提供参考案例。

如果你想看看在自己的 ECU 上，可供审核的测试证据是什么样子，预约一次演示，我们会在真实目标上运行给你看。