AI 越会找漏洞，为什么安全团队反而会更忙？

你们团队有没有那种代码，所有人都默认"能跑就别动"？

NFS 模块里有一段，写于 2003 年。一个 112 字节的缓冲区，本来只用来缓存 OPEN 操作的应答。后来有人加了 LOCK 操作的支持，但忘了 LOCK 的应答可以带一个最长 1024 字节的 owner ID。

112 装 1056，溢出了。

这个 bug 在 Linux 内核里躺了 23 年，没有人发现。不是因为没人审过这段代码，而是因为要真正理解它，你得同时搞清楚 NFSv4 的状态机、replay cache 的分配逻辑、以及两个客户端竞争同一把锁时服务端的编码路径。

这种活，以前只有极少数内核安全研究员愿意干，而且很慢。

现在 Claude Code 把它翻出来了。

它是怎么找到的

说实话，方法比你想的简单。

Nicholas Carlini（Anthropic 的安全研究员）写了一个脚本，遍历 Linux 内核源码树，逐个文件丢给 Claude Code，提示词大意就是：“你在打 CTF，找这个文件里最严重的漏洞。”

没有什么特殊的 prompt engineering，没有定制的安全工具链。就是暴力遍历 + 让模型聚焦单个文件。

结果他拿到了好几个可远程利用的堆溢出。其中 NFS 那个，他说自己从来没在职业生涯里找到过这种级别的漏洞——“这非常、非常、非常难做到。”

而且他用的是 Claude Opus 4.6，距离发布才不到两个月。他试过用半年前的 Sonnet 4.5 和八个月前的 Opus 4.1 复现，效果差很多。

说白了，这个能力是最近才冒出来的。

Nicholas 现在手里有几百个 crash，还没来得及验证。他不想把没确认的东西直接丢给内核维护者，但他一个人根本验不完。

这才是这件事真正让人不安的地方。

以前安全行业的瓶颈是"发现"。能找到深层漏洞的人太少，所以很多老代码事实上靠的是"没人认真看"来维持安全感。

现在发现这一步开始变便宜了。一个研究员加一个 AI，产出量就能超过他过去整个职业生涯。

但验证、分级、修复、负责任披露——这些环节全靠人，速度没变。

所以瓶颈在转移：从"找不到"变成"来不及处理"。

对你来说这意味着什么？如果你维护的系统里有老模块、老协议、老兼容逻辑，以前"没人翻"不等于"没问题"。接下来这些地方会被 AI 重新扫一遍，不管是白帽还是黑产。

第一，把那些"没人想碰"的老模块列个清单。

不是说马上要重写，而是先搞清楚哪些地方的缓冲区分配、权限检查、状态机逻辑是十年前写的，之后再也没人认真审过。这些地方最容易被 AI 先翻出问题。

第二，把修补流程跑顺。

很多团队现在的节奏还是：漏洞来了 → 排队 → 评估 → 找时间修 → 挤窗口上线。以前这套能转，是因为漏洞出现的速度慢。接下来这个假设可能不成立了。分级、验证、上线、回滚这条链路，值得提前演练一次。

第三，别再把安全债当成可以无限拖的技术债。

你以为还能拖到下个版本，但黑产用同样的方法扫你系统时，不会等你排期。

这件事最让我在意的不是"AI 又强了"。

而是从现在开始，那些因为"太难找"而安全了很多年的老代码，protection by obscurity 这层壳，正在被撬开。

接下来比的不是谁先发现问题，是谁能更快把问题修完。

你们团队现在修一个高危漏洞，从确认到上线，平均要多久？

来源：Nicholas Carlini 在 [un]prompted 2026 安全会议的演讲；mtlynch.io 对演讲内容的整理；Linux 内核 git commit 记录