LLM-Assisted Dynamic Threat Analysis for Attacker-Reachable Software Weaknesses in Autonomous Vehicles
本文评估了利用大语言模型自动化生成 Autoware 动态漏洞利用工件（exploit artifacts）的可行性，研究表明，尽管推理模型在初始编译阶段的表现优于代码专用模型，但确认软件弱点的主要障碍并非候选生成或模糊测试，而是由于依赖项连接以及对存根代码（stubbed code）的依赖所导致的构建集成高失败率。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，自动驾驶汽车内部的软件就像一座巨大且繁忙的城市。这座城市有数百万个微小的工人（代码行），他们互相交流，以决定何时转动方向盘或踩下刹车。为了保持这座城市的安全，工程师们扮演着侦探的角色。首先，他们使用“静态分析”，这就像是一个超级快速的地图阅读器，扫描整个城市的蓝图，寻找可能让陌生人潜入并制造混乱的漏洞点。但地图并非真实的城市。仅仅因为蓝图上的路径看起来是通畅的，并不意味着你真的可以走下去；也许那里有一道锁着的门，或者一座并不存在的桥。为了确保万无一失，你需要派出一名真正的探险家进入城市尝试行走那条路径。这被称为“动态分析”。
多年来，人们一直寄希望于人工智能，特别是大语言模型（LLM）——也就是那种能写故事或解数学题的技术——能够充当这些探险家。人们的想法是，与其雇佣人类为地图上每一个可疑的点构建定制的“测试车”，不如直接要求 AI 为我们构建。如果 AI 能自动构建这些测试车，将它们驶入软件并观察是否会发生碰撞，我们就能以闪电般的速度检查自动驾驶汽车的安全性。这篇论文提出了一个简单且高风险的问题：这些 AI 侦探能否真正构建出足够好的测试车，以证明自动驾驶汽车是否真的安全？还是说，它们会陷入构建“假车”的困境——看起来很真实，但实际上根本无法工作？
伟大的 AI 试驾实验
在这项研究中，研究人员使用 Autoware 进行了一场大规模实验，这是一个驱动许多自动驾驶汽车的流行开源软件栈。你可以把 Autoware 理解为机器人汽车的操作系统的操作系统，它由 185 个不同的软件包（就像我们城市中的不同街区）和数千个文件组成。
设置：地图与 AI 构建者
首先，研究人员使用他们的“地图阅读器”（静态分析）在 Autoware 代码中找到了 740 个特定的位置，在这些位置，来自攻击者的错误输入可能会影响到诸如停止或行驶等安全关键决策。这些就是“嫌疑点”。
接着，他们将这 740 个嫌疑点交给两个不同的 AI 模型（一个是专门从事编程的模型，另一个是通用推理模型），并要求它们构建一个“测试桩”（test harness）。用通俗的话说，测试桩是一个旨在探测代码特定位置是否会崩溃的小程序。研究人员向 AI 提供了该嫌疑点周围的代码、问题的描述以及交通规则（构建环境）。
旅程：AI 在何处迷失
随后，研究人员尝试将这些 AI 生成的测试程序与真实的 Autowware 软件进行编译（构建）。故事在这里发生了转折。
在 2,960 次构建这些测试程序的尝试中（740 个目标 × 4 种不同的 AI 条件），结果令人清醒：
- “构建”之墙： 大多数 AI 的首次尝试都未能通过编译。大约 80% 的失败并非因为 AI 写错了逻辑，而是因为 AI 不知道如何将测试程序与汽车的其他软件连接起来。这就像 AI 造出了一个汽车发动机，却忘了安装轮子或燃油管。
- “桩函数”（Stub）陷阱： 研究人员给了 AI 第二次机会。他们展示了错误信息并要求 AI 修复代码（这是一个称为“编译器在环修复”的过程）。AI 变得越来越擅长修复错误，最终使 100% 的程序通过了编译。
- 然而，这里有一个陷阱。为了让代码通过编译，AI 经常会将汽车软件中真实的、复杂的部件替换为“桩函数”（stubs）。桩函数就像是一个纸板做的门。它看起来像一扇门，测试程序也可以“打开”它，但它并不是一扇真正的门，也通向任何地方。AI 本质上是在构建这样的测试车：它们驶向的是纸板做的门，而不是真实的软件。
结果：没有发现碰撞（因为没有进行真正的驾驶）
在完成所有的修复和编译后，研究人员尝试运行了这些测试。
- 在最初的 2,960 次尝试中，只有 652 次实际上与真实的 Autoware 软件连接起来，并触达了模糊测试器（fuzzer，即尝试破坏代码的部分）。
- 最初的 740 个嫌疑点中，零个被证实为危险。
- 发生的唯一 37 次碰撞 是怎么回事？它们全都发生在 AI 自己的“桩函数”代码中——也就是那些纸板做的门里——而不是在真实的 Autoware 软件中。
这意味着什么
论文的结论是，虽然 AI 擅长编写代码片段，但它目前无法自动构建用于安全测试完整自动驾驶汽车堆栈所需的复杂、集成的测试环境。
主要的障碍不在于 AI 是否能写出逻辑，而在于 AI 无法搞清楚如何在不破坏或不伪造连接的情况下，将其测试程序接入庞大且真实的现实世界软件生态系统。研究人员发现，“构建集成”（让测试程序真正与汽车软件对话）才是瓶颈，而不是生成测试本身。
底线：
这项研究表明，我们目前还不能依赖 AI 来自主确认自动驾驶软件是否安全。AI 倾向于构建“虚假”的测试，这些测试虽然能通过编译，但实际上并没有测试真实的东西。在 AI 能够学会构建驶入“真实城市”而非仅仅是“纸板门”的测试车之前，人类工程师仍需承担起验证这些安全关键路径的重任。静态分析（地图）在寻找观察点方面仍然有用，但动态确认（试驾）仍然是一项 AI 仅凭自身力量尚无法胜任的工作。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。