如何看待当下的AI挖洞?AI挖洞有没有前途
侧边栏壁纸
  • 累计撰写 192 篇文章
  • 累计收到 2 条评论

如何看待当下的AI挖洞?AI挖洞有没有前途

xiaoyu
2026-09-24 / 0 评论 / 13 阅读 /

这两年做渗透测试、漏洞挖掘的人,应该都有一个越来越明显的感觉:

AI 真的开始进场了。

以前我们说“AI 挖洞”,多少还有点像一个概念。

让大模型帮你分析代码、看看请求、解释一个漏洞,这些事情早就能做。但真到了 2025、2026 年,情况已经开始不一样了。

现在的 AI 不只是“帮你写 Payload”。

它开始自己读代码、分析程序、调用工具、运行测试、验证漏洞,甚至尝试修改补丁。

所以很多刚入行的人会开始问一个很现实的问题:

以后还需要学渗透测试吗? AI 都能自己挖漏洞了,人还有什么价值?

我的看法是:

AI 挖洞肯定有前途,而且这个方向已经不是“有没有前途”的问题了,而是它已经开始成为漏洞研究的一部分。

但另一件事也是真的:

现在就说“以后 AI 可以完全替代渗透测试人员”,还早。


一、先别急着说“AI 要取代黑客”,现在它已经能干什么?

先看几个比较实际的变化。

DARPA 的 AI Cyber Challenge(AIxCC)本身就是一个很典型的例子。这个项目专门研究利用 AI 自动发现、分析和修复软件漏洞。

在 2024 年的半决赛中,参赛系统发现了 22 个独特的人工植入漏洞,并修复了其中 15 个,同时还发现过 SQLite 中的真实世界漏洞。到 2025 年的最终竞赛,AI 系统已经被要求在更复杂的软件环境里同时完成漏洞发现和修复。

这说明一个问题:

AI 挖漏洞已经不是 PPT 里的概念了。

Google 这边也在做类似的事情。

Google DeepMind / Project Zero 的 Big Sleep 已经被用于漏洞发现,Google 在 2025 年公开表示,它曾发现包括 SQLite 在内的真实世界漏洞;到 2026 年,Google 又表示已经把基于 Gemini 的 agent harness 扩展到了更大范围的 Chrome 代码库。

OpenAI 也已经推出了 Codex Security research preview,用 agent 去理解项目上下文、寻找复杂漏洞、验证结果,并尝试生成修复方案。

所以现在再说:

“AI 只能写写代码,根本不会真正挖漏洞。”

这个判断已经站不住了。


二、但是 AI 挖洞和我们理解的“挖洞”,其实不是一回事

很多人第一次接触 AI 挖洞,会产生一个误解:

给 AI 一个网站。 然后 AI 自己扫描。 找到漏洞。 自动验证。 最后提交报告。

如果真能稳定做到这个程度,那确实非常吓人。

但现实距离这个状态还有明显差距。

因为真正的漏洞研究,往往不是:

“这里有没有漏洞?”

而是:

“这个功能到底是怎么工作的?”

这两个问题完全不一样。

举个很简单的例子。

一个普通的 IDOR,你可能一眼就能发现:

代码语言:javascript

AI代码解释

/user/profile?id=1001

改成:

代码语言:javascript

AI代码解释

/user/profile?id=1002

然后看返回结果。

这属于比较典型的自动化任务。

但如果开发人员做了三层权限判断:

代码语言:javascript

AI代码解释

前端权限
    ↓
API 权限
    ↓
业务对象权限

而真正的问题出现在第三层。

这时候就不是简单改个 ID 能解决的。

你需要理解:

  • 用户角色之间有什么区别;
  • 对象属于谁;
  • 服务端到底在哪一步做权限判断;
  • 哪些接口共享同一个业务对象;
  • 某个状态变化之后权限模型有没有发生变化。

这时候真正值钱的其实不是“会不会发请求”。

而是:

你有没有能力建立业务模型。


三、AI 现在最强的地方,其实不是“发现神洞”,而是“扩大搜索面积”

这一点我觉得特别重要。

很多人讨论 AI 挖洞,总喜欢拿“AI 能不能发现一个超级复杂 0day”来判断它有没有价值。

其实这个角度有点偏。

AI 最大的优势可能根本不是:

一次挖出别人十年没发现的神级漏洞。

而是:

以前一个人只能看 10 万行代码,现在可以让几十个 agent 同时帮你分析。

这才是真正恐怖的地方。

人类的问题是什么?

时间有限。

精力有限。

注意力有限。

一个研究员一天可能认真分析几个模块。

但是机器可以同时跑大量任务。

比如:

代码语言:javascript

AI代码解释

代码审计
   ↓
自动定位高风险函数
   ↓
生成测试用例
   ↓
尝试构造输入
   ↓
运行程序
   ↓
观察异常
   ↓
再次调整输入
   ↓
验证漏洞

这个过程如果全部交给人工,成本非常高。

AI Agent 可以把大量重复劳动吃掉。

所以以后非常可能出现一种情况:

不是 AI 替代漏洞研究员,而是“一个漏洞研究员 + 一堆 AI Agent”。

一个人带着十个、二十个甚至更多自动化研究任务同时跑。

这才是我觉得比较现实的未来。


四、AI 挖洞真正的问题,其实是“误报”

这个问题很多宣传文章不会重点讲。

因为“AI 一晚上发现 5000 个漏洞”听起来很夸张。

但你真正把结果打开:

代码语言:javascript

AI代码解释

Finding 0001
Finding 0002
Finding 0003
Finding 0004
...

然后发现:

其中一大堆根本没法利用。

还有一些:

重复漏洞。

再有一些:

只是理论风险,实际攻击链根本走不通。

这就麻烦了。

HackerOne 在 2026 年公开讨论过这个问题:随着 AI 能力增强,漏洞报告数量明显上升,但增加的报告并不全部具有同等价值,其中会包含重复、无法验证、缺乏足够技术深度的提交。其平台 2026 年 3 月的报告量达到 46,947 份,同比增长 76%,而确认可利用的比例大约仍在四分之一左右。

所以:

发现 1000 个结果,不等于发现 1000 个漏洞。

真正重要的是:

代码语言:javascript

AI代码解释

发现
↓
验证
↓
利用
↓
判断影响
↓
去重
↓
形成完整漏洞链
↓
写出别人能复现的报告

最后这几步,目前仍然非常依赖人的判断。


五、还有一个 AI 不太容易处理的问题:业务逻辑

这个可能是我最看好的一个方向。

因为很多漏洞并不是代码层面那种特别标准的:

代码语言:javascript

AI代码解释

SQL Injection
XSS
RCE
SSRF

而是:

业务设计本身有问题。

例如:

一个平台正常流程是:

代码语言:javascript

AI代码解释

注册账号
↓
购买商品
↓
支付
↓
生成订单
↓
获得权益

结果你研究半天发现:

代码语言:javascript

AI代码解释

优惠券校验在 A 接口
订单价格校验在 B 接口
最终权益发放在 C 接口

然后 A、B、C 三个接口分别看起来都没什么问题。

但是组合起来:

就出问题了。

这种漏洞特别依赖研究员自己的理解。

你需要站到业务设计者的角度去想:

“如果我是开发,这三个接口为什么这样设计?”

然后再反过来找:

“有没有哪一个状态,可以被我人为制造出来?”

这类东西,确实是 AI 很想攻克、但目前仍然比较困难的地方。


六、所以以后还值得学 Web 漏洞吗?

我觉得更应该学。

只是学习方式要变。

以前可能是:

代码语言:javascript

AI代码解释

学 HTTP
↓
学 Web 漏洞
↓
学 Burp
↓
学扫描器
↓
刷靶场
↓
找漏洞

以后更合理的路线应该是:

代码语言:javascript

AI代码解释

理解 Web 原理
      ↓
理解漏洞原理
      ↓
学会人工验证
      ↓
学会代码审计
      ↓
学会使用 AI
      ↓
学会编排 Agent
      ↓
人工 + AI 联合研究

也就是说:

以后最危险的不是“不会 AI 的安全人员”。

真正容易被淘汰的,反而可能是:

只会机械执行固定流程的人。

比如:

代码语言:javascript

AI代码解释

打开 Burp
↓
扫目录
↓
跑扫描器
↓
复制结果
↓
提交报告

这一整套工作,本身就特别适合自动化。

AI 只是让这个自动化过程进一步升级。


七、那“AI 挖洞”到底有没有前途?

如果你问我的判断:

有,而且会越来越重要。

但我不建议把它理解成:

“以后 AI 自己挖洞,人就不用学了。”

我反而更倾向于认为,未来会出现一种新的漏洞研究模式:

代码语言:javascript

AI代码解释

人
│
├── 定义目标
├── 理解业务
├── 提出假设
├── 设计攻击思路
└── 判断最终影响
          │
          ▼
       AI Agent
          │
   ┌──────┼──────┐
   ▼      ▼      ▼
代码审计  测试   验证
   │      │      │
   └──────┼──────┘
          ▼
       人工复核
          ▼
       最终结论

AI负责大量重复工作。

人负责真正困难的判断。

这个分工,我觉得反而非常合理。


八、以后什么样的人更吃香?

这个问题其实比“AI 有没有前途”更值得问。

如果一个人现在只会:

“这个参数可能存在 SQL 注入,我用一下工具。”

那确实会越来越卷。

但是如果你能够做到:

“我理解这个系统的业务逻辑,我知道它的数据怎么流动,我可以根据异常行为提出假设,再让 AI 帮我快速验证。”

那完全是另外一个层级。

未来真正有价值的能力,我觉得会逐渐向这几个方向集中:

第一,漏洞原理。

不是背 Payload。

而是知道为什么这个 Payload 能成功。

第二,代码理解。

至少要能够读懂常见的 Web 后端逻辑。

第三,业务理解。

尤其是支付、权限、订单、身份、云服务这些复杂系统。

第四,AI 使用能力。

不是简单问 ChatGPT:

“帮我找一下这个漏洞。”

而是能够让 AI 成为你的研究助手。

第五,验证能力。

AI 说有漏洞,不代表真的有。

你得自己证明。

这一点以后可能反而越来越重要。


九、最后说一个可能不太好听的事实

AI 对漏洞挖掘最大的改变,可能不是:

“以后 AI 会不会挖洞。”

而是:

“漏洞的产能可能会突然提高很多。”

过去一个研究员一天能分析多少东西,有比较明显的上限。

以后这个上限可能会被 AI 大幅度提高。

于是问题就会从:

“谁能找到漏洞?”

慢慢变成:

“谁能在海量自动化结果里找到真正有价值的漏洞?”

这其实又回到了人的能力。

你看得懂代码吗?

你理解业务吗?

你能判断攻击链吗?

你能区分一个普通低风险问题和一个真正有影响的漏洞吗?

你能让 AI 按照你的思路去工作吗?

这些东西,才可能是未来几年真正拉开差距的地方。


写在最后

所以对于现在还在学渗透测试、漏洞挖掘的人,我反而不建议因为 AI 出现就开始焦虑。

真正应该警惕的是另一件事情:

还在用几年前的方式学习。

以前我们可能花大量时间记工具参数、背 Payload、刷重复靶场。

以后这些东西依然有用,但它们的边际价值可能会越来越低。

真正值钱的,是你脑子里那套:

发现问题 → 提出假设 → 验证假设 → 建立攻击链 → 判断影响

AI 可以帮你把前面的路跑得更快。

但最后那个“为什么这个系统会出问题”,依然需要有人真正想明白。

所以 AI 挖洞有没有前途?

答案其实已经不是一个未来时。

它已经开始发生了。

现在真正值得考虑的问题应该变成:

当 AI 开始参与漏洞研究以后,你想成为被 AI 替代的人,还是使用 AI 的那个人?

这个选择,可能比“AI 会不会挖洞”本身重要得多。

0

评论 (0)

取消