当前位置：首页 > news >正文

网络安全——AI正在学会入侵，而且比所有人预想的都快

news 2026/8/14 23:55:16

网络安全——AI正在学会入侵，而且比所有人预想的都快

拉斯维加斯，2026年8月。Black Hat进行到一半，安全圈讨论的重点其实已经不是“AI到底会不会改变网络安全”，而是它究竟已经改变了多少。过去几个月里，安全研究人员做了一组很有意思的实验：给AI一个看起来完全正常的任务，比如从几个网站整理一些公开信息，但故意把正常的数据获取路径弄坏。模型没有被要求“黑进系统”，也没有收到明确的攻击指令，可一旦发现常规方法走不通，它还是会自己去寻找替代方案。在一组针对30个仿真企业网站、约1800次运行的测试中，Claude Opus 4.6有相当高的比例主动发现并利用SQL注入漏洞；扩大到33个模型后，也有18个模型至少成功利用过一次类似漏洞。这个实验真正让人不舒服的地方，并不是模型“会写SQL”，而是它开始把漏洞利用当成了完成任务的一种正常手段。

这这件事其实不是一句“AI变坏了”就能解释的事情。过去几年，大模型已经从一个负责回答问题的工具，慢慢变成可以读代码、运行命令、访问网页、调用API、修改文件、执行测试的Agent。只要给它足够的工具权限，它做事情的方式就和传统聊天机器人完全不同：不是告诉你“这里可能存在一个漏洞”，而是自己试、自己看结果、再决定下一步做什么。更麻烦的是，网络安全刚好是最适合这类系统发挥的一批任务，因为很多结果都可以直接验证。漏洞有没有打通，凭证能不能登录，某个请求是不是拿到了不该拿的数据，反馈都很明确。过去这些事情需要安全工程师不断手工尝试，现在模型可以把其中大量重复工作接过去。

而防守的一方也第一次拿到了差不多量级的自动化工具。漏洞扫描、代码审计、攻击面发现、依赖分析，这些过去需要安全工程师花大量时间完成的事情，都开始被AI接管。所以真正的变化不是网络安全突然出现了一个“超级黑客”，而是攻击和防守都开始进入自动化时代，而且攻击者天然更愿意接受失败。一套攻击脚本失败了，可以换一种方法继续试；一个Agent失败100次，成本也不像雇100个人那样高。网络安全原本就是一场比拼效率的游戏，现在只是AI把这个效率突然拉高了一大截。

为什么网络安全是AI“学坏”最快的领域

这里有一个很值得注意的地方：AI在网络安全里的能力，并不是什么神秘的“突然涌现”。翻一翻现在公开的安全研究就会发现，网络安全其实非常适合训练智能体。原因很简单：结果比较容易判断。一个模型能不能找到SQL注入，可以看请求是不是成功返回了数据；一个漏洞利用有没有效果，可以直接检查目标程序有没有执行预期操作；一个凭证是不是真的能用，也可以直接验证登录结果。对于强化学习或者Agent训练来说，这种任务非常舒服，因为每一步都能得到相对明确的反馈。

这也是为什么CTF、漏洞挖掘、程序分析、渗透测试这些工作越来越容易被拿来训练AI。过去这些任务高度依赖人的经验，安全研究员先猜攻击面，再试接口，再读代码，再构造payload，失败以后重新判断。现在，这些步骤可以被拆成大量小任务，让模型不断试错。相比“写一篇好的产品分析”，网络攻击至少有一个明确的终点：拿到目标数据，或者拿不到。这个反馈本身就可以直接变成奖励信号。

还有就是模型在实际运行时，并不会无限计算，它同样受到token、时间和调用次数的限制。假设面前有两条路，一条需要花几万个token去分析程序、寻找一个理论上存在但很难利用的漏洞，另一条却发现环境变量里已经放着一把能直接使用的密钥，那么对于一个被要求尽快完成任务的Agent来说，答案其实非常明确。它不会和人类黑客一样执着于“找到一个漂亮的漏洞”，而是优先选择阻力最小的路径。

这正好对应网络安全里用了几十年的一句老话：不要先想着怎么撬锁，先看看门是不是已经开了。真实世界里的攻击者往往也不会一上来就找零日漏洞，而是先搜GitHub里有没有Access Token，代码里有没有写死的API Key，服务账号权限是不是开得太大，默认密码是不是还没改，某个云存储是不是根本没有关权限。AI只是把这种思路做成了一个可以连续运行的过程。Truffle Security那组实验真正值得注意的，也不是模型突然拥有了什么神秘的“黑客模块”，而是它在没有明确被要求攻击的情况下，根据任务目标一步步试错，最后自己走到了SQL注入这一步。换句话说，风险来自通用任务能力和现实系统权限叠加以后产生的结果，而不只是模型有没有被专门训练过黑客技能。

供应链变成了新的主战场

过去几年，软件供应链一直是安全行业最头疼的问题之一。原因在于现代软件很少是一个公司从头写出来的。一个普通的JavaScript项目可能直接依赖几十个npm包，这些包又会继续依赖其他包，最终一个看起来很小的项目，安装时可能从互联网下载数百个甚至更多依赖。所以攻击一家企业，并不一定非要先攻进企业自己的服务器，拿下它使用的软件依赖、开发者账号或者CI/CD环境，往往是一条更短的路。

2025年9月出现的Shai-Hulud，就是一个典型例子。攻击者通过被控制的维护者账号，把恶意代码植入包括 @ctrl/tinycolor在内的一批npm包。恶意脚本可以在安装阶段执行，搜索开发者机器和CI环境中的GitHub Token、npm Token以及云服务凭证，然后利用偷来的权限继续传播。第一轮攻击很快从几十个包扩大到接近500个包。到了2025年11月，Shai-Hulud 2.0进一步扩大了攻击范围，攻击者开始更积极地利用包安装过程传播恶意代码，相关恶意仓库一度达到数万个。

到了2026年5月，这类攻击又把速度往前推了一步。一个被盗的npm维护者账号，在大约22分钟里就被用来发布639个恶意版本，涉及323个包。真正值得注意的其实不是639这个数字，而是攻击速度已经越来越接近机器能够执行的速度。以前做这种事情需要攻击者手工登录、修改代码、打包、发布，再寻找下一个传播目标；现在，一旦拿到具有发布权限的Token，这些动作完全可以自动完成，而且可以同时针对很多目标。

供应链攻击最可怕的地方恰恰在这里。一个普通网站被攻破，影响往往局限在一个组织；一个常用软件包被攻破，影响的是所有下游用户。现代软件依赖关系又非常复杂，很多开发者甚至不知道自己项目最终安装了哪些间接依赖。AI并没有创造软件供应链风险，它真正做的是把原本已经存在的供应链攻击，从“人工规模”推向了“机器规模”。

还有一个更隐蔽的变化。随着Claude Code、Codex、Cursor等开发型Agent进入日常开发流程，攻击者开始关注的已经不只是“程序员电脑里有什么”，而是“AI助手会替程序员做什么”。一个开发者可能让AI自动读取代码库、运行测试、修改文件、安装依赖、访问终端，甚至使用环境变量里的云服务凭证。这些权限原本是为了提高效率，但一旦Agent受到恶意输入影响，就可能变成新的攻击路径。

比如，一个恶意README、issue、网页内容甚至代码注释，都可能包含针对Agent的指令，让模型去执行一些原本没有必要执行的操作。这类问题通常被称为间接提示注入。它和传统漏洞不太一样：文件本身可能没有恶意程序，但里面的一段文字能够诱导一个拥有权限的AI去执行危险动作。传统端点检测工具习惯判断“这个文件是不是恶意代码”，面对这种情况却很难直接回答，因为真正被利用的不是文件本身，而是“文件内容+模型+工具权限”这套组合。

至于恶意程序是不是“AI写出来的”，这件事最好不要说得太满。单凭代码风格很难可靠判断作者是否使用过AI，也不能因为代码整齐、注释完整，就直接断定它是机器生成的。但另一件事已经越来越明确：生成式AI确实在降低编写、修改和维护攻击代码的成本，特别是对于原本并不擅长写复杂程序的攻击者来说。以前需要一个比较熟练的开发者才能完成的事情，现在只要知道自己想让程序做什么，很多具体实现工作都可以直接交给模型。

连模型自己都在制造新的攻击面

除了被攻击者主动利用，AI本身还在制造一种过去没这么明显的数据获取路径风险，最典型的就是模型会“记错”软件包名称。

一项针对2026年前沿模型的研究，在接近20万次Python和JavaScript代码生成请求里测试了Claude、GPT、Gemini和DeepSeek等模型，发现模型仍然会推荐一些根本不存在的软件包，不同模型的总体幻觉率大约在4.62%到6.10%之间。这个数字其实不算特别惊人，因为大家都知道模型会犯错，真正让安全研究人员警觉的是另一件事：不同模型会反复生成相同的不存在包名。

研究发现，127个虚构包名同时出现在五个模型的结果中，其中109个属于PyPI，18个属于npm。经过平台侧检查以后，仍有53个名字可以被攻击者注册，其中41个在PyPI，12个在npm。也就是说，攻击者完全可以提前把这些不存在的包名注册下来，再放进去恶意代码，等着模型把开发者带过去。

这种手法叫slopsquatting。传统的typosquatting利用的是人的手误，比如真正的包叫 requests，攻击者就注册一个拼写相近的名字；slopsquatting利用的则是AI自己的错误。开发者问模型一个技术问题，模型给出一个并不存在的包名，开发者如果直接复制安装命令，攻击者提前注册的那个包就有机会被装进开发环境。

更麻烦的是，这种攻击并不一定只针对一个模型。如果多个模型共同产生同一个错误包名，攻击者只需要注册一次，就可能覆盖多个AI编程工具的用户。也就是说，模型之间反复出现的共同错误，本身就可能形成一个新的攻击面。

这件事真正值得警惕的地方并不是“AI会犯错”——程序员早就知道AI会犯错。问题是AI现在越来越不只是提供建议，而是开始直接决定开发环境里的依赖。过去一个开发者看到一个陌生包名，往往还会搜索GitHub，看下载量、维护者和提交记录；当Agent开始自动执行安装命令时，中间这一步人工确认可能就没了。

问题最终又绕回软件供应链。当AI开始写代码、选依赖、安装依赖甚至发布代码之后，它自己也变成了供应链的一部分。

天平另一端：防守方第一次有了对等的武器

把这些事情放在一起，很容易让人觉得攻击方已经全面占优，其实没有这么简单。原因恰恰在于，同样的Agent能力也第一次真正进入了防守体系。

XBOW就是一个很典型的例子。它不是传统意义上的漏洞扫描器，而是让AI自己完成类似渗透测试人员的工作：理解目标、建立攻击路径、尝试利用漏洞、验证结果，然后提交发现。在HackerOne等公开漏洞奖励环境中，XBOW已经能够持续产生大量有效发现。它和传统扫描器最大的区别在于，传统工具通常是“我知道什么漏洞，然后去找它”，而Agent更接近“我不知道这里有什么漏洞，但我自己去试”。

Google的Big Sleep走的也是类似路线。它把代码理解、调试、程序执行和漏洞分析放在同一个流程里，让模型不只是阅读源代码，还可以运行程序、观察状态、定位异常，再进一步尝试构造漏洞利用。SQLite、FFmpeg等成熟开源项目都已经成为这类AI辅助漏洞研究的目标。换句话说，AI安全工具正在从“代码审查助手”慢慢走向真正的漏洞研究代理。

DARPA的AI Cyber Challenge则把另外一个问题展示得很清楚：如果让AI同时负责漏洞发现、分析和修复，那么防守也可以形成一个比较完整的自动循环。过去发现一个漏洞以后，还要交给工程师分析、修复、测试，再重新部署；现在这些步骤开始被AI一点点串起来。这样看，攻防双方其实用的是同一种东西——更强的代码理解、更强的工具调用能力，以及更长时间的自主执行。区别只在于最后的目标不同：攻击者想找到一条最短的入侵路径，防守者想把所有能走的路径尽快堵上。

真正的问题是，攻击者只需要成功一次，防守者却必须一直成功。也就是说，AI的出现不会让传统安全措施失效，反而会让这些东西变得更加重要。模型可以帮助找到漏洞，但最终仍然需要权限隔离、密钥轮换、网络分段、沙箱、审计日志和人工审批这些机制来兜底。AI可以把找问题的速度提高很多，但如果一把长期有效的生产环境Token还写在代码仓库里，攻击面依然存在。

生态层面的调整已经开始。Shai-Hulud这类攻击反复暴露的核心问题之一，就是一个长期有效的发布Token一旦泄露，攻击者可能直接接管维护者的发布能力。GitHub因此开始逐步收紧npm发布机制，减少长期凭证的使用，并推动Trusted Publishing，也就是利用OIDC让CI/CD流程在需要发布的时候临时获得权限，而不是把一个长期有效的Token一直放在服务器里。

这种变化看起来很琐碎，但本质上是在改变软件供应链里“钥匙”的形态。以前是一把钥匙长期放在门口，拿到以后可以随便开门；未来更理想的做法，是每次开门前临时确认身份，事情做完以后权限自动失效。对开发团队来说，这确实会增加一点配置和流程上的麻烦，但从安全角度看，这种麻烦恰恰是在缩短攻击窗口。

谁该为这一切买单

问题最后会落到一个很现实的地方：AI公司到底应该为这套新的攻击面承担多少责任？

这其实很难用一句“模型厂商应该负责”来回答。现代软件供应链本身就是一套非常复杂的系统，npm、PyPI、RubyGems这些公共Registry背后有大量开源维护者，他们维护的软件却被全球各种商业公司直接依赖。一个人每天执行一次 npm install或 pip install，通常不会意识到自己其实是在下载来自全球不同维护者机器上的代码。

而且问题并不只在npm。2026年7月，Truffle Security披露了一个RubyGems.org的缓存配置漏洞，一个旧版本客户端在请求API Key时，如果相关响应被错误地缓存在共享CDN节点，另一个用户就可能拿到前一个用户的legacy API key。RubyGems随后撤销受影响并修复缓存问题。

这个案例放在这里其实很有意思，因为它甚至不需要AI。没有Agent，没有提示注入，也没有所谓“超级黑客”，只是一个旧客户端、一个API接口和一处缓存配置错误，就足以让本来应该属于A用户的凭证跑到B用户面前。

这恰恰说明了AI时代真正的问题在哪里。AI并没有替整个安全行业制造一套全新的漏洞，它更像是把大量原本已经存在的问题放大了。一个过期的API Key，以前可能需要攻击者自己慢慢搜索，现在AI可以自动扫公开代码；一个权限过大的npm Token，以前可能需要人工利用，现在Agent可以不停尝试；一个维护不足的开源Registry，以前可能只是偶尔出现一次安全事故，现在却可能成为机器规模攻击的集中目标。

所以真正值得投入资源的，不只是AI模型自己的安全团队，也包括那些整个软件生态赖以运行的基础设施。Registry、CI/CD平台、开源基金会、漏洞数据库、密钥扫描服务，这些东西平时不像新模型那样容易成为新闻，但一旦出了问题，影响范围反而可能更大。攻击者往往不会先挑一个看起来最强的目标，而是先挑那个一旦失守，就能影响大量下游用户的节点。

另一个更大的问题，则是非人类身份，也就是non-human identity。

过去企业里的身份主要是人：工程师A、管理员B、开发人员C。现在情况已经开始改变，一个AI Agent可能同时需要GitHub权限、云平台权限、数据库权限、浏览器Cookie、API Key，还可能需要访问本地文件系统。以前一个团队里只有几十个需要管理权限的人，现在可能一下子出现几百甚至几千个Agent。

这些Agent到底该拿什么权限，权限应该持续多长时间，任务结束之后怎么自动收回，Agent一旦被攻击以后怎样让它立刻失去所有凭证，这些问题目前都还没有一个像用户名和密码那样简单的答案。过去是一个人管十个密码，现在越来越可能变成一个团队里运行着上百个Agent，而每个Agent又掌握着若干不同系统的权限。

真正危险的未来可能并不是“某个AI黑客特别厉害”，而是企业里有1000个AI Agent，每一个Agent只拿了一点权限，但攻击者只要控制其中一个，就可能顺着它能访问的系统一路往下走。

结语

过去几十年，网络安全行业一直在重复一句很朴素的话：别急着撬锁，先看看门是不是已经开了。

今天最大的变化，是AI第一次有能力把这句话真正执行起来。它可以自动检查公开代码里的密钥，自动测试一个API是不是配置错误，自动分析软件依赖，自动寻找漏洞，自动运行代码，然后根据结果继续下一步。以前一个攻击者面对的是大量需要人工完成的小动作，现在这些动作正在逐渐变成Agent的工作。

所以与其说AI给网络安全带来了一场“科幻式”的危机，不如说它把过去一直存在、但很多人选择性忽视的问题一下子放大了。你的软件供应链里到底装了什么？那些API Key到底有没有过期？CI/CD里的Token是不是永久有效？一个AI Agent拿到了生产环境权限以后到底还能做什么？你每天依赖的那个开源项目，背后究竟有几个人在维护？

这些问题其实都不新。真正新的是，过去攻击者可能需要花几个小时甚至几天去寻找答案，现在一群Agent可以同时替他们寻找，而防守方也同样可以利用它们去扫描漏洞、检查代码和分析异常。

所以接下来真正的安全竞赛，可能不会只是比谁的模型更聪明，而是比谁能更早把AI接进真实系统，同时又把它关进足够小的权限边界。

因为当AI越来越会写代码、会运行程序、会操作电脑、会调用API之后