安全工程师不够用：自动化、AI 与零已知问题达到 SOP
汽车安全专家远远不够，无法在每个版本上测试每一个 ECU。AI 驱动的自动化让小团队依然能以零已知问题达到 SOP。
Tom Zaubermann · 发布于 · 8 分钟阅读
做这项工作的人不够。这是汽车网络安全背后令人不安的事实，而且情况正在恶化，而不是好转。
这笔账算不过来
ISC2 的劳动力研究将全球网络安全人才缺口定在数百万量级，按其 2026 年的估计约为 480万，整个行业需要增长约 87% 才能满足需求。约 90% 的安全团队报告存在技能缺口。
现在把范围收窄到汽车行业。测试一个 ECU 不是通用的 IT 安全。它需要懂 CAN 和 CAN FD、UDS 和 DoIP、SecurityAccess、诊断会话以及嵌入式目标实时约束的人，而且这些人还得能把所有这些映射到 ISO/SAE 21434。这是一个本就短缺的领域中极小且早已超负荷的子集。与此同时，汽车网络安全市场正在快速增长，从 2026 年的约 40 亿美元，迈向 2030 年代初的 120 亿美元乃至更高。需求在攀越悬崖，而真正能测试一个控制单元的人才池几乎纹丝不动。
再算算工作量。一个现代整车项目有几十个 ECU。每个 ECU 在投产前都有许多版本，投产后还有更多。如果深度安全测试依赖于为每个 ECU 的每个版本预约屈指可数的几位专家之一，那么排队的时间会比项目周期还长。总得有什么让步，而通常让步的是测试。
SOP 是一堵只会撞上一次的墙
量产启动日期不会移动。当车辆到达 SOP 时，安全缺陷的代价会完全改变：产线启动前只是一条代码审查意见，启动后就变成一次现场行动或召回。而在 UN R155 和 ISO/SAE 21434 之下，你不能简单地交付然后祈祷。你必须证明缓解措施经过了测试，已知问题得到了处理。
所以真正的目标很具体：在没有任何已知低垂果实的情况下到达 SOP。不是一个完美的 ECU，没人能承诺这一点，而是一个那些显而易见、影响重大、第一个小时就能发现的问题已被消除并记录在案的 ECU。无需认证即可访问的诊断服务。薄弱或默认的 SecurityAccess。暴露在外的 XCP 或 CCP。本应锁定却可写的标识符。这些问题很常见，破坏力极大，而且完全可以避免，前提是有人在每个版本上都去测试它们。
最后那个前提就是整个问题所在。一次 SOP 前的渗透测试只是你那一周手上软件的一张快照。ECU 一直在变。两个冲刺之后新增的一个功能悄悄地重新打开了某个服务，而在下一次审核之前没人再测试，到那时它已经装进了车里。
招人解决不了，但可以放大
本能的反应是招更多专家。这个本能是对的，但不够，因为市场上没有人可招，而且即便团队扩大一倍，也无法手动重测每个 ECU 的每个版本。
这正是 AI 和自动化改变单位经济学的地方，值得把“如何改变”说得精确一些。AI 本身不会填平技能缺口，谁要是告诉你它能取代你的安全工程师，那是在推销东西。它真正擅长的，是让你现有的团队升级：把一名优秀测试人员手工所做的事情编码进无需他在场即可运行的引擎，让稀缺的人力专注于只有人才能做的工作。
具体来说，如何枚举一个 UDS 协议栈、探测 SecurityAccess、安全地对一个接口做模糊测试，或者遍历一个 DoIP 网关，这类知识是稳定且可重复的。它不需要每次都有专家在场。它需要专家出场一次，构建测试，然后由机器在之后的每个版本上永远运行下去。专家由此被解放出来，去研究新颖的攻击路径、TARA，以及自动化无法想象的事情。
在真实项目中是什么样子
这正是 AutoST 的用武之地。它的引擎承载着测试知识：UDS 枚举、SecurityAccess 分析（0x27）、UDS 和 CAN 模糊测试、DoIP 和 SOME/IP、Android IVI。你只需把 ECU 接上一次台架，从此 AutoST 就通过 API 运行并集成在 CI 中。
于是测试从“审核前，如果有专家有空的话”变成了“每个主要版本上自动执行”。每个 ECU 的每个构建都会得到同样的基线安全检查。低垂果实在被引入的那一刻就被抓住，而不是在车里才被发现。到 SOP 时，你手上有一条带日期的轨迹，表明每个版本都经过了测试，已知问题都已关闭，而这也恰恰是 ISO/SAE 21434 评估员想看到的。
而你手头那寥寥几位安全工程师，也不必再把宝贵的时间花在第四十个 ECU 上重新发现同样薄弱的 SecurityAccess。他们把时间用在真正需要人的攻击上。
坦诚的说法
自动化不会让安全工程师变得多余。它让你已有的工程师发挥最大价值。AutoST 负责广度和回归，让一个小团队能够覆盖整个整车项目，并在没有任何已知低垂果实的情况下到达 SOP。深度、创造力、TARA 和审核仍然需要人，而 Zyberum 同样提供这些，团队已带领 Tier 1、Tier 2 和 OEM 项目走完了同样的路。可应要求提供参考案例。
如果你的项目中 ECU 的数量比安全工程师还多，而几乎所有项目都是如此，那么这个缺口正是 AutoST 要弥合的问题。预约一次演示，我们会向你展示测试每个版本到底是什么样子。
FAQ
常见问题
AI 会取代汽车安全工程师吗？
不会。AI 和自动化负责广泛且可重复的测试：已知攻击模式、回归测试、低垂果实。新颖的攻击路径、TARA 和创造性工作仍然需要专家。像 AutoST 这样的工具，意义在于放大你手头为数不多的专家，而不是取代他们。
为什么要在每个主要版本上测试 ECU，而不是只测一次？
因为 ECU 在每个版本上都会变化，而一次 SOP 前的渗透测试只能说明你那一周手上的软件。安全退化会随着新功能悄悄混入。测试每个主要版本，是在没有已知问题的情况下进入量产的唯一途径。
ECU 安全中的“低垂果实”指什么？
指一名称职的测试人员在第一个小时内就能发现的问题：无需认证即可访问的诊断服务、薄弱或默认的 SecurityAccess、暴露在外的标定接口、可写的标识符。它们很常见、影响重大，而且正是自动化可以在每个构建上捕获的那类问题，这样人就永远不必再亲自去找。