我本是一名普通的小白帽，有一天上班路上，遇到了位神秘老者，他拦住我，问道：小伙子，你是做什么的？

我大声回答：我是挖洞的！

老者摸着胡须，目光炯炯望着我：刚刚我看路边有人弄丢了几把铲子，想必是你弄丢的，那让我来考考你，你丢的是这把金铲子，还是这把银铲子呢？

我说：不是金铲子，也不是银铲子。

老者笑意更浓：对啦对啦，剧情就是这样，那你丢的是这把铁铲子吧？

我再次回答：都不是，也不是铁铲子。

老者急眼了，铲子一扔问我：不对啊，金银不是，铁的也不是？那你到底用什么铲子挖洞啊？？

我挺起胸膛朗声回答：这你就不知道了吧！我是用混元大模型来挖洞的，我做了一个可自动挖掘0day漏洞的代码漏洞检测工具，还在GitHub好几个热门开源项目里，挖到了10多个真实且至今未披露的0day漏洞呢！wink（手动波浪号）

漏洞挖掘的技术研究主要包含几大方向：基于规则引擎的静态分析、基于代码动态分析、基于机器学习和深度学习驱动，以及近2年兴起的基于大语言模型自动化扫描。其主要实现及优缺点如下。

以下面这个简单的例子来说明基于大模型的漏洞检测相比传统静态分析的优势。

该示例代码中，静态分析方法通过匹配输入和输出的规则判断是否符合漏洞判定条件，却忽视了在代码语义逻辑上相关执行条件是否会成立，从而导致误报；而大模型通过语义理解，一步步的逻辑推断和执行条件分析，最终正确判定示例代码不存在漏洞。

综合分析可知，对于0day漏洞挖掘场景，较为适用的方法是代码动态分析（如模糊测试）和基于大模型的漏洞分析。然而，代码动态分析虽然具备一定的0day漏洞挖掘能力，但是存在依赖执行环境、结果黑盒、执行耗时等诸多问题。因此，我们将专注于探索基于大语言模型的漏洞分析，也就是方案四（图2）。

根据最新的文献调研，大模型应用于漏洞挖掘的方向大致可分为这几类：直接基于大模型驱动、大模型辅助模糊测试、大模型辅助静态分析等。其效果表现和局限性如下。

图4 大模型应用于漏洞挖掘文献调研现状

在2024年10月以来，谷歌等部分企业也已对外宣称通过借助大模型能力挖出了0day漏洞。因此，大模型应用于自动化漏洞检测的可行性被初步验证。

为了进行漏洞的快速挖掘,避免问询资源的浪费, 通过调用大模型对代码入口文件进行初步的漏洞类型评估, 筛选出存在薄弱点的高危文件, 从而更聚焦在特定漏洞类型进行漏洞分析，提高准确性。

调用大模型进行多轮对话轮训，并根据轮训结果，结合上下文补充信息，逐步进行代码深入分析。

当出现以下几种情况的时候，工具会停止分析，并输出漏洞报告：

• 分析深度超过某个阈值；
• 大模型认为已经获得了漏洞点后返回结果；
• 分析到未知的开源组件代码,并完成漏洞特征推断后结束对话并返回。

图6 在GitHub的Top热门项目中捕获的部分0day漏洞详情

• 某知名AI类应用产品漏洞

• 某知名工具类产品漏洞

本次实战已初步验证AI自动化挖掘0day漏洞可行。但大模型在自动化漏洞挖掘的落地过程中，还有很多问题值得我们深入探索和解决。譬如：

• Token限制和遍历深度问题

当前版本设计中，可通过大模型的java语法分析能力有效摘取上下文，从而应对项目级代码漏洞检测对于token数约束的挑战。即便如此，在成熟的java项目体系中，也有不少漏洞具备多文件、多层级函数调用的特点。由于token数约束问题始终客观存在，导致该工具只能在有限的深度阈值内进行漏洞检测，从而可能遗漏部分高价值的漏洞。

• 大模型普遍存在的幻觉问题

大模型的泛化能力带来了发现未知组件漏洞的好处。与此同时，大模型的幻觉问题也会导致误判。比如，将正常的函数调用误认为是漏洞点，加大了漏洞验证的成本。此外，大模型可能输出自我构造的上下文请求，导致语法分析出错，从而导致漏洞报告准确性受影响，进而造成一些误报。

下个版本，我们将持续优化上述问题，提供更丰富的功能，并在更多安全应用场景中推动落地。

欢迎大家在评论中共同探讨这款工具的更多可能性，也希望大家多多关注我们的大模型助力安全系列文章，一起碰撞出更多思想火花，共同提升行业整体安全防护水平。

• 大模型应用实践（一）：AI助力Code Review安全漏洞发现
  
• AI助力！明文密码泄漏无处遁形【大模型应用实践系列二】