← 最新论文
🤖 AI

Correct Code, Vulnerable Dependencies: A Large Scale Measurement Study of LLM-Specified Library Versions

这项大规模测量研究揭示,由于对特定高风险版本的系统性偏见,大语言模型在生成的 Python 代码中频繁指定存在漏洞且不兼容的第三方库版本,从而凸显了人工智能辅助软件开发中一个关键且此前被忽视的风险面。

原作者: Chengjie Wang, Jingzheng Wu, Xiang Ling, Tianyue Luo, Chen Zhao

发布于 2026-05-08
📖 1 分钟阅读☕ 轻松阅读

原作者: Chengjie Wang, Jingzheng Wu, Xiang Ling, Tianyue Luo, Chen Zhao

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

想象一下,你正在聘请一位超级聪明、速度极快的私人助理来为你的软件项目编写代码。这位由大型语言模型(LLM)驱动的助理非常擅长编写逻辑:“这是你锁门的方法,”或者“这是你发送消息的方法。”

但有一个陷阱。为了让代码运行,助理需要使用现成的“工具”(第三方库)。本文研究的问题在于:助理不仅仅是抓取工具;它会抓取这些工具的特定、过时甚至有时已损坏的版本,而且你对此毫无察觉。

以下是用简单类比对研究发现的分解:

1. “食谱”与“购物清单”

研究人员测试了两种向助理请求代码的方式:

  • “内联”模式:你请求一段代码片段,助理编写代码,并在每个工具旁边添加一个小注脚,写着“使用工具 X,版本 1.0"。
  • “清单”模式:你要求助理编写一段代码片段,同时编写一份单独的工具“购物清单”(即 requirements.txt 文件)。

研究发现:
当被要求提供“内联”注脚时,助理非常热衷于指定确切版本(95% 的情况下)。但当被要求提供“购物清单”时,它突然变得懒惰和模糊,经常留空版本号(仅在 6% 到 59% 的情况下)。

  • 类比:这就像一位厨师,当被要求写食谱时,他说:“使用确切的 2015 年份盐。”但当被要求为整个厨房写购物清单时,他只写了“盐”,留给你自己去决定买哪一年的盐。

2. “过期牛奶”问题(安全风险)

研究发现,当助理确实选择了特定版本时,它往往选择一个危险的版本。

  • 数据:在 37% 到 56% 的情况下,助理选择的特定版本存在已知安全漏洞(即"CVE")。
  • 严重程度:这些漏洞大多属于“严重”或“高”级别。
  • 转折:这些漏洞并非秘密。它们在助理接受训练之前就已经是公开知识。助理只是不知道要避开它们。
  • 类比:想象这位助理是一个时间旅行者,总是挑选三年前过期的牛奶。尽管过期日期早在几年前就印在包装盒上了,但助理仍然不断递给你那盒过期的牛奶,以为它是新鲜的。

3. “趋同”效应(每个人都选择了同样的坏东西)

你可能会认为不同的 AI 模型会选择不同的版本。事实并非如此。

  • 研究发现:所有测试的十个模型(来自谷歌、OpenAI、阿里巴巴等)都收敛到了完全相同的一小套风险版本。如果助理选择了“工具 X",它几乎总是选择“版本 2.31.0",即使存在更新、更安全的版本。
  • 类比:这就像城市里的每一个人,无论背景如何,都决定购买同一双已知鞋底破损的鞋子。这不是巧合;这是从同一本旧教科书中习得的共同习惯。

4. “坏钥匙”问题(兼容性)

即使工具不危险,它也可能无法匹配。

  • 研究发现:助理选择的版本往往无法安装,或者无法与他们编写的代码协同工作。
    • 静态检查:代码甚至无法安装(就像试图把方钉塞进圆孔)。
    • 动态检查:即使安装了,当你尝试运行代码时,代码也会崩溃。
  • 原因:助理喜欢选择非常旧的工具版本。这些旧版本依赖于现代计算机中已被移除的计算机系统组件。
  • 类比:助理编写的代码说:“打开灯”,但它指定了一个 1990 年的灯泡,该灯泡需要一个在你 2026 年的房子里不存在的灯座。代码本身完美无缺,但灯泡根本拧不进去。

5. 为什么我们不能只是“告诉”助理做得更好?

研究人员尝试了几种方法来修复这个问题:

  • “请保持安全”提示:他们告诉助理:“请不要使用存在安全漏洞的版本。”
    • 结果:无效。助理仍然选择了糟糕的版本。
    • 原因:助理并不是“忘记”了规则;它只是没有连接到实时的安全警告数据库。这就像要求一个背诵了 2023 年教科书的学生去避开 2025 年通过的新法律。他们脑子里 literally 没有这些信息。
  • “外部锚点”修复:当研究人员强制助理使用预先批准的 safe 版本列表(就像人类提供的严格购物清单)时,问题消失了。
    • 结果:安全风险降低,代码实际上也能运行了。

结论

该论文得出结论:LLM 擅长编写代码的“逻辑”,但它们在管理工具的“供应链”方面表现糟糕。

它们就像一个乐于助人但不可靠的图书管理员,递给你一本看起来完美但实际上是危险且过时的版本的书。你不能信任它们建议的具体版本号。你必须将它们视为草稿,并在使用前始终使用安全工具双重检查版本号

问题不在于 AI“愚蠢”;而在于 AI 是基于旧数据训练的,这使其倾向于流行但过时的版本,并且缺乏与当前安全警告的实时连接。在 AI 连接到实时安全工具之前,人类开发者必须负责检查过期日期。

您所在领域的论文太多了?

获取与您研究关键词匹配的最新论文每日摘要——附技术摘要,使用您的语言。

试用 Digest →