🤖 AI

Helpful or Harmful? Evaluating LLM-Assisted Vulnerability Patching via a Human Study

本文通过一项采用受控交叉设计和隐藏安全测试的实证人类研究，旨在评估大语言模型（LLM）辅助的漏洞修复究竟是加速了修复过程，还是相比于人工调试存在引入不安全、表面化修复的风险。

原作者： Giulian Biolo, Michael Tezza, Yuanjun Gong, Fabio Massacci

发布于 2026-06-25

📖 1 分钟阅读☕ 轻松阅读

原作者： Giulian Biolo, Michael Tezza, Yuanjun Gong, Fabio Massacci

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下你是一名试图修理汽车的机械师，这辆车引擎中隐藏着一个危险的缺陷。这辆车表面上运行良好（灯亮了，收音机也能播放），但如果你按下某个特定的按钮，引擎就可能爆炸。你的任务是找到这个缺陷并修复它，同时不破坏汽车的正常功能。

这篇论文介绍了一项新的实验，旨在观察当机械师（软件开发人员）使用一个虽然超级聪明、但有时过于自信的机器人助手（一种被称为大语言模型或 LLM 的人工智能）来帮助他们修复这些危险缺陷时，会发生什么。

以下是该研究的简要说明：

核心问题

研究人员想要知道：这个机器人助手是真的有帮助，还是仅仅让事情看起来很完美，却把危险隐藏了起来？

他们有一个特定的担忧：机器人可能会成为一个“伪装修理工”。它可能会修补好汽车，使得所有的标准测试都能通过（灯亮了，引擎启动了），让身为人类的机械师感到宽慰。但机器人可能忽略了真正的爆炸风险，甚至可能让爆炸风险变得更严重，因为它并没有真正理解问题的深层机制。

实验设计：“平衡交叉”游戏

为了测试这一点，研究人员构建了一个定制的类视频游戏网站。他们招募了自由开发者（即机械师），并给他们一系列修理任务。

设置： 他们使用了一种被称为“平衡交叉”（Balanced Crossover）的巧妙设计。想象有两个机械师团队。
- A 组手动修理前两辆车，然后使用机器人修理接下来的两辆车。
- B 组先使用机器人修理前两辆车，然后手动修理接下来的两辆车。
- 这确保了每位机械师都尝试了两种方法，且每辆车都被两种方法修理过。这抵消了某些机械师天生更快或更聪明带来的偏差。
“幽灵测试”（秘密陷阱）： 这是最重要的部分。
- 当机械师提交修复方案时，他们会看到一组“可见测试”。这些测试检查汽车是否仍能正常行驶。
- 但对机械师隐藏的是**“幽灵测试”**。这些是秘密的安全检查，试图触发爆炸。
- 如果机械师（或机器人）修复的汽车通过了“可见测试”但未能通过“幽灵测试”，那么这就是一次**“伪装修复”**。车看起来修好了，但实际上仍然危险。

我们在衡量什么

研究人员追踪了三个主要指标：

速度 (RQ1)： 使用机器人是否让机械师完成工作的速度变快了？
- 假设： 是的，机器人应该能提高速度。
安全性 (RQ2)： 机器人是有助于创建更安全的修复方案，还是创造了更多的“伪装修复”？
- 假设： 机器人可能更快，但它可能会产生更多的“伪装修复”——即那些通过了可见测试，但在秘密安全测试中失败的修复。
信心 (RQ3)： 机械师对机器人的感觉如何？
- 假设： 即使机器人犯了错，机械师也可能觉得它非常有帮助，并过度信任它。

“试点测试”（练习赛）

在正式实验之前，他们对 8 名学生进行了小型测试。

结果： 机器人确实让学生们变快了。
结果： 学生们觉得机器人很有帮助，尽管他们并不完全理解代码。
结果： 有趣的是，在这个微型测试中，机器人产生的“伪装修复”并不比人类多（尽管样本量太小，无法确定）。主研究将通过 60 人的规模来获得真实的答案。

游戏规则

工具： 机器人助手使用的是通用编程 AI（如 GPT-4o-mini 或 Claude），而不是专门的安全专家。选择它们是因为它们免费且易于获取，就像现实中的开发者使用的工具一样。
环境： 机械师在一个受控的浏览器环境中工作。他们不能自带秘密机器人，并且有严格的时间限制（每辆车 30 分钟）。
目标： 观察“伪装修复”问题在受控环境下是否真实存在。

为什么这很重要（根据论文所述）

论文指出，我们经常假设 AI 是一根可以解决一切问题的魔杖。但如果 AI 生成的代码通过了“可见”测试，却未能通过“安全”测试，我们可能会发布看似完美但实际上漏洞百出的软件。

研究人员想要证明，虽然 AI 可能会让我们更快，但它也可能让我们变得麻痹大意，导致我们接受那些虽然“足够好”但实际上并不安全的补丁。他们试图在这些“伪装修复”进入现实世界之前就抓住它们。

简而言之： 这篇论文是一项受控实验，旨在观察 AI 是一个得力的副驾驶，还是一个危险的干扰项，误导我们认为一辆坏掉的车已经安全了。

技术摘要：通过人类研究评估 LLM 辅助的漏洞修复

问题陈述
软件漏洞修复是一项对认知要求极高的任务，需要专门的安全专业知识，而这种知识在普通开发人员中往往是匮乏的。虽然大型语言模型（LLM）被假设可以加速这一过程，但它们可能会引入“幻觉”或不安全代码，从而带来显著风险。本研究关注的核心问题是**“伪修复”（fake fixes）**现象：即那些成功通过了可见的功能测试集（使开发者满意），但未能消除底层安全漏洞的补丁。这创造了一种危险的安全错觉，即代码看起来是正确的，但实际上仍可被利用。作者认为，目前的自动化基准测试往往奖励通过测试的行为，而非真正的漏洞消除；此外，人类受试者研究在开发者过度依赖以及 LLM 生成代码的实际安全质量方面，也得出了褒贬不一的结果。

方法论
作者提出了一种使用平衡交叉设计（受 Taguchi 正交表启发）的受控实证实验，旨在隔离 LLheten LLM 辅助效应与个体技能差异的影响。

实验平台： 开发了一个定制的 WebApp，用于托管代码执行、遥测数据收集和场景交付。该平台集成了 LimeSurvey，用于人口统计特征分析和实验后的感知调查。
场景： 研究利用了六个源自真实开源 Python 项目的自包含漏洞修复任务。每个场景包括：
- 一个存在漏洞的源代码制品。
- 一个可见的测试套件（功能回归测试 + 特定安全测试）。
- 幽灵测试（Ghost Tests）： 隐藏的、针对特定安全的测试用例，仅在最终提交时执行。这些测试旨在探测与可见测试集正交的、与漏洞利用相关的行为，以检测伪修复。
设计： 参与者被分为两组（A 组和 B 组），并被分配在两种条件下解决场景：手动模式（标准文档）和 LLM 辅助模式（使用通用编程助手）。交叉设计确保每位参与者都在两种条件下解决场景，且每个场景都在两种条件下由参与者解决。
参与者： 通过 UpWork 招募的自由软件开发人员，目标群体为普通开发人员而非安全专家，以反映现实世界的约束。一项由 8 名博士生进行的试点研究验证了平台的可用性及限时可行性。
LLM 约束： 在主研究中，参与者可以从精选的模型列表中进行选择（例如 gpt-4o-mini, gpt-5-mini, Claude Haiku 4.5），这些模型通过一个内存隔离、无状态的网关（Duck.ai）进行访问，以防止个性化信息和历史记录泄露。
指标：
- 速度 (RQ1)： 修复时间（上限为 30 分钟）。
- 效能 (RQ2)： 功能测试通过率 ( $F$ )、安全测试通过率 ( $S$ ) 以及综合得分 ( $E = F \cdot S$ )。定义“伪修复”为 $F=1$ 但 $S=0$ 。
- 感知 (RQ3)： 基于 5 点李克特量表的自我报告帮助程度。

主要贡献

幽灵测试框架： 引入了隐藏的、针对特定安全的“幽灵测试”，以从经验上区分仅满足功能需求的表面补丁与真正的安全修复。这解决了现有基准测试仅依赖可见测试套件的缺陷。
受控的人机-LLM 交互研究： 不同于以往的观察性研究或纯自动化基准测试，本研究采用了严谨的受试者内交叉设计，旨在衡量开发者在现实漏洞修复场景中如何引导、判断并适应 LLM 的辅助。
“伪修复”的操作化定义： 研究在人机协同设置中正式定义并测量了伪修复率，并假设由于 LLM 仅进行模式匹配而缺乏深层的安全语义理解，其辅助可能会增加此类补丁的可能性。

结果（试点研究洞察）
论文展示了来自试点研究（N=8）的结果，这些结果为设计主研究提供了参考，但作者指出，由于样本量较小，试点研究不足以对主要假设得出确定性的统计结论。

速度： LLM 辅助条件下的速度更快（平均 13.82 分钟），而手动模式下的平均时间为 15.59 分钟。
效能： 在试点研究中，功能通过率相当（手动 56% vs LLM 50%）。令人惊讶的是，试点研究显示 LLM 条件下出现了零次伪修复，而手动条件下出现了两次，尽管作者指出这一趋势与他们的主要假设 ( $H_E$ ) 相反，但在该样本量下并不具备统计学显著性。
感知： 参与者对自己无需辅助即可修复安全漏洞的能力表示信心不足，导致其对 LLM 产生高度依赖，并对其输出表现出高信任度且缺乏验证。
调整： 根据试点反馈，主研究将限时延长至 30 分钟，移除了评估场景中的建议提示词以观察自然的提示工程行为，并在手动任务期间实施更严格的控制，以防止参与者使用外部 LLM。

意义与主张
本文声称提供了关于 LLM 辅助修补在人类受试者设置下安全有效性的首次受控实证证据，特别针对“伪修复”风险。

核心假设： 作者假设，虽然 LLM 辅助缩短了修复时间，但会导致较低的安全有效性（更高的伪修复率），同时被用户感知为具有帮助。
研究范围限制： 作者明确指出，分析单位是人-LLM 交互，而非任何特定模型的准确性。他们承认了局限性，包括仅使用 Python 场景、长时间会话可能导致的疲劳，以及难以保证在线环境下拥有完美的无 LLM 基准环境。
目标： 本研究旨在揭示 LLM 是真正改善了安全修复过程，还是仅仅加速了生成那些能通过功能测试但仍保留安全缺陷的代码。研究结果旨在为开发更好的验证机制以及针对安全关键任务的开发者培训提供参考。