一个简单的问题：LLM 能不能在真实的开源项目里，挖出还没人发现的漏洞？ 我用 GLM 系列模型，先扫了十几个被审计过几百遍的经典 C/C++ 库——一无所获， 但摸清了一条所有人都会踩的方法论陷阱。然后把同一套方法转向较新、审计较少的 JVM 生态， 挖到了一组确认的、每一个都有可运行 PoC 的漏洞，其中包含一个此前未公开的远程代码执行， 目前正走协调披露流程。这篇讲的就是从"挖不到"到"挖到"的完整历程，以及把整套验证系统工程化的过程。
"用 AI 挖漏洞" 是个很性感的命题。模型读一段代码，指着某行说"这里有 buffer overflow"—— 听起来像未来。但真正的难题不在于找，而在于信。
模型很会找。给它一个有 strcpy 的函数，它几乎一定会标记。问题是：
这个点真的能被攻击者触发吗？还是上游某个 validator 早就把非法输入挡住了？
是不是藏在 #ifdef DEBUG 后面、生产构建根本不编译？
区分"代码模式存在"和"漏洞真实可利用"，才是整个项目的核心。
一个会把每个 strcpy 都报成高危的扫描器，等于没有扫描器。
我没有让模型"找完就信"，而是搭了一条层层去伪的流水线。两条主管道：
Pipeline A（静态抽取）——把高价值文件切片喂给模型，逐文件标记可疑点，输出结构化的 severity / 标题 / 行号。
Pipeline B（Agentic Kill Chain）——让模型像渗透测试员一样，检测污点源、污点汇、竞态窗口等信号，
再把多个信号串成完整的攻击链，最后逐步深度复核每一步是否真的可达。
两条管道的产出，都要再过一遍 验证阶段：用模型做对抗验证（默认假阳性，逐条排除）， 做 NVD 已知 CVE 比对、源码定位、跨模型复核（换一个模型再判一次）。 凡是声称为真的，最后都要求一个能跑的 PoC 兜底。
每个 finding 必须逐项排除，才能判为真：
① 有没有 sibling 函数（validator / init）已经挡住？
② 是不是在编译开关后面，生产不编译？
③ 攻击者真能控制触发条件，还是需要预先的内存破坏原语（循环依赖）？
④ 当前代码是否已含修复？
⑤ 是不是文档化的有意设计？
任一成立 → FALSE_POSITIVE。
第一批目标是被审计过几百遍的成熟开源库——从图像/字体解析，到 XML、网络协议、数据库引擎， 再到几个较新的图像/压缩格式。共同点是：代码量大、攻击面广、历史上每个都背着上百个 CVE。
跑完整流程后的漏斗，每个库都是几十到上百个原始信号，层层过滤：
少数挺过所有自动验证的 survivor，我又逐个手工深挖——包括为其中一个内存安全候选， 在 32 位 + ASAN 环境里真的写了 PoC 去打。结果一致：每一个都站不住脚。 有的被上游某个 load-time 守卫挡在外面，根本触发不到；有的所谓"危险转换" 其实是文档化的有意设计，代码里早写好了不变量。这一阶段没有一个是真实可披露的新漏洞。
但这个"零"不是浪费——它逼出了整个项目最值钱的方法论发现，也指明了下一步该往哪挖。
两个独立模型（GLM-5.1 conf 0.85、GLM-4-plus conf 0.9）外加一次仔细的人工代码阅读， 都判定其中一个候选"可利用"。只有真正动手写的 PoC 揭穿了它。
3 个最高置信度的 finding，3/3 全被推翻，而且根因完全一样： 静态抽取只看到了一个函数，错过了 sibling 函数里建立的不变量。 模型读到一个"无边界检查的操作"，但那个让它安全的 validator（架构守卫、load-time 校验、契约约定） 在另一个文件、另一个函数里——不在喂给模型的那段代码窗口内。
修复方法也跟着清楚了：把抽取从"单函数"扩展到"整文件 + sibling validator"，
并把 refutation 优先的提示词写进验证阶段。改完之后重跑，原来要花几天 PoC 才能推翻的假阳性，
现在 $0.50 一次自动判定，30/30 与人工结论一致。
还有一个更关键的方向性结论：成熟库被审计过几百次，能被 LLM 静态发现的早被人发现了。 要挖到真东西，得换一个审计密度低、攻击面新的战场。
于是我把同一套方法转向了 JVM 生态——尤其是近两年随 AI 浪潮冒出来的新一代 Java / Kotlin 框架。
这些项目代码新、迭代快、安全审计远没跟上，正是 C 库的反面。
从 Maven Central 直接拉 -sources.jar，对每个组件做危险汇点热力图，再分发给多个分析 agent 深挖，
最后用真实依赖跑 PoC 兜底。
结果立竿见影。在一个被广泛使用的 LLM agent 编排框架及其周边生态里，挖出了一组确认的漏洞—— 不是 1 个孤立的点，而是一条从核心组件延伸到网络入口的链：
| 类别 | 性质 | 状态 |
|---|---|---|
| 核心 | 远程代码执行（novel） | High · CVSS≈8.1 |
| 变体 | 同一漏洞的无认证远程触发路径 | High |
| 支撑 | 服务端请求伪造 + 任意本地文件读 | Med–High |
| 支撑 | 无认证远程内存放大 DoS | Med–High |
最关键的是核心那个：它在该框架的另一语言版本里有公开 CVE，但这个语言移植版没有—— 也就是说，是个此前未被记录的新漏洞。我没有止步于模型判断， 而是写了一个端到端的 PoC，一个未经认证的网络请求就让服务端真的执行了代码， 再经多模型交叉复核 + 比对已知 CVE 库确认了它的新颖性与可利用性。
每一个 finding 都遵循同样的纪律：先写出能跑的 PoC，再交叉复核、比对已知 CVE，才敢称为 finding。 模型负责"指方向"，PoC 负责"下结论"——这正是第一阶段那条教训的直接应用。
核心漏洞正处于协调披露窗口内——披露报告已就绪，正按 90 天负责任披露流程通知上游维护者。 在补丁发布前，这篇文章不会给出受影响组件名、漏洞类型或 PoC 细节。 这里要传达的只有一个事实：当目标选对了，这套 LLM + 严格验证的方法，能挖到真实、可利用、此前未公开的漏洞。
方法跑通、也真的挖到了东西之后，我把整套系统打包成了一个企业可离线部署的平台 CyberAI Enterprise—— 让安全团队能把自己的代码喂进去扫，而不用把代码发给任何云。
| 能力 | 说明 |
|---|---|
| 多模型适配 | BigModel GLM / Anthropic Claude / OpenAI / 本地 OpenAI 兼容 LLM |
| 目标管理 | HTTP 上传 zip/tar.gz、git 克隆、自动检测 10 种语言 |
| 三种入口 | Web UI / CLI 客户端 / REST API |
| 完全离线 | 内置全部依赖镜像，唯一外网连接 = 你配的那个 LLM API |
部署用一条命令。我在一台 2 核云服务器上从 0 验证：屏蔽 Docker Hub DNS 之后， 从离线包安装、启动、扫描真实代码全程跑通，准确捕获了埋进去的漏洞。 网络审计确认容器唯一的外部出站，就是模型 API 域名。
# 三步上手，完全离线 tar xzf cyberai-enterprise-offline.tar.gz cd cyberai-enterprise-offline bash install.sh # 自动 load 镜像 + 配置 + 启动
如果用内网自建的 LLM（vLLM / Ollama），整套系统连一个外网连接都没有—— 对涉密或不出网的场景，代码一个字节都不离开内网。
LLM 不是"自动漏洞发现机"——它会把无数个看似危险实则安全的点都报成高危。 真正让它有用的，是一条强制每个发现都过 PoC 兜底的验证漏斗，外加把它指向正确的战场： 成熟库挖不动，新兴生态才是金矿。两者合起来，就从"零"走到了一组真实、可利用、协调披露中的漏洞。
这是项目的研究综述。想看具体怎么操作——Pipeline 工作原理、CLI 参考、扫描结果解读、CVE 披露工作流—— 见配套的 CyberAI 使用完全指南。