人工智能编程助手正在成为软件开发的新常态，但一项最新安全研究揭示了一个令人不安的现象：这些AI工具推荐的许多开源软件包实际上处于“无主”状态——没有任何个人或组织对它们负责。安全隐患随之而来：一旦这些包被恶意行为者接管，成千上万的企业网络可能成为攻击目标。
227条命令背后的惊人发现
据Ars Technica报道，安全研究人员在企业内部文档中扫描到了227条安装命令，这些命令指向的代码包没有任何归属者。换句话说，这些代码是“孤儿软件”——它们的原始作者可能已经放弃维护，或者从未明确声明所有权，但企业系统仍在信任并安装它们。
更值得警惕的是，这些安装命令并非来自默默无闻的脚本，而是出自目前最流行的AI编程工具：Anthropic的Claude、GitHub的Copilot/Codex，以及各类基于大语言模型的编码辅助系统。研究人员指出，AI模型在训练过程中学习了大量历史代码仓库和教程，其中包含许多已被遗弃的依赖项，而模型在生成代码时并不具备判断代码包是否仍被维护的能力。
“AI编程助手本质上是一种概率性软件推荐引擎。它根据训练数据中的常见模式生成代码，而不是基于对第三方库当前生态状态的实况分析。这导致它反复推荐那些曾经流行但如今无人维护的软件包。”
供应链攻击的新温床
无主代码的威胁在于，任何人都可以尝试宣称对这些包的所有权。攻击者只需注册同名包，或利用维护漏洞向旧版本中注入恶意代码，就能把后门扩散到使用AI生成代码的企业系统中。这种做法在安全领域被称为“依赖混淆”或“抢注劫持”。
近年来，开源生态中已多次出现因维护者丧失兴趣而导致的投毒事件。2024年，安全公司Checkmarx曾披露过一个名为eth-account的恶意库，它通过模仿热门包名称，成功骗过AI模型进入开发者项目。而本次发现的无主代码问题更为棘手——它们不是模仿品，而是AI直接引用的“正主”，企业安全团队往往对这些包抱有盲目信任。
企业CIO的困境：AI提效与安全如何兼得？
对于企业而言，AI编程助手带来的生产力提升不可否认，但本次研究再次证明：安全治理必须同步跟上。专家建议，在使用AI生成代码时，企业应强制实施以下措施：
一是构建私有软件物料清单，对所有依赖项进行来源审计；二是使用安全扫描工具识别“孤儿包”和“无主仓库”；三是建立AI代码审查机制，对AI建议的第三方引用进行人工复核。
从更宏观的角度看，整个AI产业链也需要反思：大型语言模型在训练时是否应该排除那些明显已僵尸化的开源项目？模型提供商是否应该在推荐依赖包时附带维护状态提示？这些问题比单一企业的安全策略更具紧迫性，因为它们关乎整个软件供应链的基础信任。
编者按：AI时代的“数字遗产”问题
无主代码的广泛存在，其实暴露了开源世界的“数字遗产”困境。当年兴致勃勃地创建库的开发者，可能早已转行、离职或失去兴趣，但他们的作品仍被成千上万的AI模型反复引用。如同废弃的城市建筑，这些代码不因无人居住而消失，反而成为危险的栖身之所。
AI编程助手放大了这种风险，因为它以极高的频率将这些无人看管的“超链接”写入新的企业软件地基中。我们不禁要问：当AI成为知识的主要传播者时，它是否也应当承担起验证信息真实性与安全性的责任？目前看来，答案还未到来，但227条安装命令已经敲响警钟。
本文编译自Ars Technica
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接