搞安全这些年我一直有个执念AI 到底能不能像资深研究员那样从几千行源码里嗅出那处“早晚会炸”的边界错误。Big Sleep谷歌安全研究团队推出的自动化漏洞挖掘项目最近用一次真实案例给了回答——它在一个已经被人工审计和长期 fuzzing 轮番轰炸过的 SQLite 源码里提前发现了一个足以被利用的内存破坏漏洞并在漏洞进入正式版本之前就把它拦了下来。这篇文章不是新闻复述我想把 Big Sleep 的定位、技术思路、SQLite 漏洞案例的细节、对安全行业的影响以及我自己复现这类 AI 审计时的实操经验一次讲清楚。适合对漏洞挖掘、对“AI 如何走向代码安全”感兴趣的朋友。如果你只是用过聊天式 AI、还没正经写过代码审计也能看懂核心逻辑因为这中间的很多思路其实并不复杂复杂的是怎么把它落到一个具体函数上。1. Big Sleep 是什么从“生成代码”到“读懂代码”的一次转身1.1 项目名字里的野心“Big Sleep”直译过来是“沉睡”的意思但放在漏洞挖掘的语境里这个名字相当巧妙让大模型在代码库里找出那些“沉睡多年”的缺陷。它脱胎于谷歌安全研究团队此前在 AI 辅助漏洞发现上的探索目标非常明确——不满足于让 AI 帮忙写代码而是让 AI 像安全研究员一样面向源码做语义级的漏洞审计。这跟我平时用代码助手的体验完全不同。日常开发时我们问 AI“帮我写个函数”“这段逻辑哪里有问题”它给的是泛化的建议正确率和上下文理解都不稳定。Big Sleep 做的事情更接近“定向审计”给它一个具体的源码文件、一个明确的危险操作清单让它在限定范围内把所有可疑路径挖出来。它不是要替代编译器或 lint 工具而是在做“这条输入到底能不能一路扭曲成一次内存破坏”的深水区推理。这里值得先说清楚一个容易误解的点Big Sleep 不是一个刚上线就全网刷屏的产品也不是一个直接开放的云服务更不是那种输入仓库路径就自动输出漏洞的工具。它更像一个实验项目发布了一系列技术报告和真实漏洞案例最有代表性的就是这次 SQLite 事件。所以你看新闻时会看到“谷歌 AI 提前阻止漏洞”这种说法准确讲是AI 在一个真实开源项目中完成了从发现到复现的完整闭环并且修复已经合入。这个“闭环完成度”才是这次事件真正值钱的地方。1.2 为什么选中 SQLite 做试金石SQLite 在整个开源生态里的地位不太夸张地说是软件地基级别的存在。它被嵌入到几乎每一部手机、每一台电脑、无数浏览器、操作系统组件和编程语言标准库里。C 语言编写核心代码二十多万行没有独立的服务器进程直接链接进宿主程序运行。这就意味着一个 SQLite 漏洞一旦被利用攻击者获得的往往不是“数据库服务器权限”而是“宿主进程的内存读写能力”——在许多场景里这基本等于拿到了应用的脸面。也正因为到处都在用SQLite 长期是全世界的 fuzzer 和人工审计者重点关照的对象。它自己的维护团队就有非常成熟的内存安全测试体系外部安全社区也翻来覆去地盯着它。在这种项目里“再挖出一个新漏洞”本身就很有含金量说明它不是那种留下明显缺陷的代码而是需要跨过大量安全检查、在特定语义组合下才会暴露问题的硬骨头。更关键的是“提前”这两个字。安全行业见惯了两种漏洞披露方式一种是研究人员发现后走负责任披露流程先报给厂商再公开另一种是漏洞已经被利用了一段时间直到出现攻击样本或大规模异常才被察觉。Big Sleep 这次属于第三种状态AI 在代码发布之前就看出了苗头漏洞从未进入稳定版本也就谈不上被利用。对 SQLite 的几亿用户来说这是最理想的结果。2. 它怎么找洞大模型审计漏洞的核心思路2.1 传统漏洞挖掘手段的盲区在哪里要理解 Big Sleep 的价值先得看看现有手段为什么漏掉了这个洞。静态分析工具SAST擅长的是规则匹配定义一批危险模式然后在源码里套。遇到“memcpy 之前没检查长度”这种直白问题效果很好。但一旦漏洞需要跨三个函数、依赖某个全局状态、只在特定错误处理分支里触发规则引擎常常无能为力因为它不理解代码意图只能看到语法结构。Fuzzing 走的是另一条路生成大量输入去撞程序靠覆盖率反馈不断变异目标是让程序走到更多分支。它特别擅长发现“某个输入直接导致崩溃”的问题但对“必须在正确语法和正确数据语义同时满足时才会触发的逻辑漏洞”就显得束手无策。举个不恰当但贴切的类比fuzzer 像是拿一串钥匙挨个试锁总有机会打开锁但如果这把锁不仅需要钥匙对还得在门被拉开 37 度的瞬间才能转动靠盲试的效率就非常低了。人工代码审计能处理这种语义复杂的问题因为人理解代码意图能顺着“这行输入从哪来”一路追到“这个析构点会不会被重复调用”。但人工审计太贵了资深研究员一天能精读多少代码几百行到一两千行已经很顶了。整个开源世界有几亿行 C/C 代码靠人海战术根本覆盖不过来。这就是 Big Sleep 想填的坑用大模型把“研究员式追问”的成本降下来。2.2 Big Sleep 的审计方法把“研究员的追问”交给模型那 Big Sleep 具体是怎么让模型干活的核心可以拆成三个问题这段代码的哪些入口接收外部可控数据这些数据有没有可能一路传导到危险操作数组写入、内存释放、整数运算、指针解引用如果传导到了中间有没有足够多的约束条件卡住它哪些约束实际上可以被绕开传统工具之所以做不好这些追问是因为它们没有“常识”。大模型不一样它在代码语料上训练过理解函数名、注释、常见开发习惯甚至能推断出“这个错误处理分支很可能只会在极端情况下走到”。Big Sleep 团队的做法就是把这些追问包装成提示词和目标代码一起喂给模型让模型输出候选漏洞、对应的调用路径、以及一个可以实际运行的触发条件。这里有个关键细节模型并不是漫无目的地读代码。研究团队会引导它聚焦在漏洞最常出现的模式上比如数组下标来自外部输入、循环边界错误、资源释放路径混乱、整数提升导致的计算异常等。把范围收紧到“危险函数输入源”的交叉区域而不是让它通读整个项目。道理很简单上下文窗口有限模型推理深度也有限与其给 20 万行代码让它发挥不如给它 2000 行和一条明确的“去查哪里”的任务。这个思路对普通人其实很有参考价值。你会发现 Big Sleep 的成功不是因为模型变得“全知全能”而是任务设计得好——它把开放的漏洞挖掘问题变成了若干个可验证、可收敛的窄问题。这也解释了为什么有些团队把模型接入项目后就期待它自动挖到一堆洞结果失望而归目标太宽任务没有边界模型自然会开始“自由发挥”。2.3 AI 与 fuzzing 的分工协同很多人第一反应是“AI 挖洞是不是要取代 fuzzing”其实恰恰相反AI 离不开 fuzzerfuzzer 也需要 AI 来打开思路。我个人的理解是这两者像“侦察兵”和“工兵”的关系。AI 负责在语义层面做推理猜测哪条路径可能有问题构造一个看起来能绕过检查的输入方向。fuzzer 负责在语法和覆盖层面做验证把 AI 给的推测转成大量实际输入跑到崩溃的那一下。反过来fuzzer 崩溃时的堆栈也可以交给 AI 去分析迅速定位到可疑函数再针对该函数做更深的人工审计。Big Sleep 的流程里两者是反复协作的不是一条单行道。这种分工还解决了 AI 的一个先天毛病——幻觉。模型很容易言之凿凿地说“这里有个越界”实际上代码完全正常或者说“这条路径可达”实际上前面有个不可满足的条件。把它的输出交给 fuzzer 和编译器运行时去跑一遍幻觉就会被现实撞碎。AI 负责提出那个“真正的难点”验证工作还是得靠没有感情的执行器来完成。3. SQLite 漏洞案例实录一条 SQL 引发的内存越界3.1 漏洞藏身的位置VDBE 指令执行引擎SQLite 在执行一条 SQL 语句时并不是像我想象中那样直接把语法树跑一遍而是先把 SQL 编译成一套字节码交给它自己内部的一个虚拟机引擎——VDBEVirtual Database Engine逐条解释执行。这个设计让 SQLite 能做到很多优化也把大量复杂逻辑集中在了一个相对有限的执行器代码里。听起来是不是特别眼熟任何一个解释器、虚拟机、字节码引擎攻击者都特别爱研究因为执行器的错误往往意味着对内存访问约束的绕过。Big Sleep 这次发现的漏洞就落在 VDBE 的某个指令处理函数里。根据公开的技术报告问题出在一个错误处理分支上当 SQL 语句触发某种特殊条件时引擎会跳到一条“极少有人注意”的处理路径而这条路径里某个寄存器数组的索引可能在边界检查之前就被使用造成越界读取。更准确地说是访问了尚未正确初始化的寄存器槽位从而读取到脏数据甚至越界内存。这样说可能有点抽象我换个角度讲VDBE 在处理指令时会维护一个“寄存器”数组相当于执行时的临时变量池。每个操作码都知道自己该访问哪些槽位正常情况下编译器生成的字节码会保证槽位合法。但错误处理路径往往不是主流程编写和维护时容易被忽略——某个操作码在遇到空值、遇到冲突、遇到需要回滚时可能会被直接推到另外一个分支而那个分支对槽位的使用假设和主路径并不一致。漏洞就是在这种“假设断裂”里产生的。3.2 触发路径与影响范围从公开信息看能触达这条路径的是一类“看起来有点别扭”的 SQL 语句大致跟带子查询的写入语句、以及冲突处理子句的组合有关。比如在执行 INSERT 且遇到唯一约束冲突、进入 DO UPDATE 分支时如果关联的子查询返回了特殊结果引擎就可能走错分支。这里我不展开骗人的精确语法因为具体语句、具体版本和补丁信息官方报告里有完整细节感兴趣的话直接对着报告复现更准确。重点说一下影响面。SQLite 的内存破坏漏洞轻则造成进程崩溃重则在嵌入了它的程序里变成可利用的内存破坏原语。因为 SQLite 几乎无处不在——浏览器本地存储、手机系统设置、即时通讯软件的聊天记录库、各类桌面软件的配置中心——一个能被触发且能稳定复现的漏洞风险等级天然就是高的。搜索引擎、系统组件、数千个 App 全都跑在上面等于地基里发现一根横梁有裂缝。不过也别恐慌所有漏洞的价值都取决于“可利用性”和“是否已到野外”。SQLite 执行 SQL 的场景通常是应用自己拼接 SQL而不是直接接收攻击者控制的文本但这并不妨碍漏洞本身的严重性因为一旦上游应用把用户输入拼进 SQL或某个 Web 场景允许构造特殊语句风险就会传导下去。这就是为什么团队选择在发布前按下暂停键。3.3 发现、上报、修复一次标准的“提前阻止”整个流程其实很符合负责任的漏洞披露范本Big Sleep 团队在某个 SQLite 开发版本里发现问题后整理出可复现的 SQL 语句和崩溃信息直接提交给 SQLite 维护团队。维护团队确认问题在源码上补上边界检查和初始化逻辑添加回归测试用例然后发布了包含该修复的新版本。这里面有两个细节值得单独拿出来说。第一这个漏洞从发现到被确认的过程非常快说明 AI 给出的触发路径和复现语句质量相当高不是那种只有个大概方向的猜测。第二修复本身并没有改动任何公开 API 或改变 SQL 语义属于彻底的内存安全加固。换句话说用户几乎无感但地基更稳了。这也让我想到很多产品发布会上的说法——“AI 帮助发现了问题”听着像营销但这次确实不是。因为从审计到复现再到交付给维护者整条链路是完整的有崩溃堆栈、有触发条件、有回归测试完全是正经安全研究员的工作产出。4. 这次事件对安全行业意味着什么4.1 漏洞发现的可规模化路径变了过去几年安全行业一直在琢磨一件事能不能把“挖洞”这件事从“依赖少数精英研究员”变成“可持续、可规模化的工程”。自动化 fuzzing 算第一步但它解决的问题主要集中在崩溃型漏洞代码量大、语义复杂、上下文跨函数的漏洞依然高度依赖人工。Big Sleep 的这次产出证明了 AI 可以补上这个空缺——不是偶尔“瞎猫碰上死耗子”而是有方法、有流程地发现真实漏洞。这会带来一个很实际的变化代码审计的门槛正在降低。以前想成为一名能审计 C 代码漏洞的研究员可能需要多年的操作系统、编译器、内存布局、调试经验积累。现在借助 AI 把可疑路径预筛一轮哪怕是一个刚入行的新人也能在提示词的引导下对高危函数做初步排查再让资深研究者集中精力处理最有价值的方向。AI 不取代研究员但它能极大放大研究员的时间。对开源项目来说这更是个好消息。热门项目如 SQLite、Linux 内核有人盯也未必盯得过来冷门但同样影响深远的项目就更不用说了。如果 AI 审计能成为开源 CI 的一部分在每次提交后自动跑一轮“可疑路径扫描”漏洞发现时间整体前移整个行业都会受益。4.2 边界与风险AI 审计不是银弹但是把 Big Sleep 神化成“从此自动挖洞”显然也不现实。我观察到的边界至少有以下几条。一是幻觉问题。模型太容易把“看起来不对”当成“确实不对”。它会脑补不存在的调用关系会给一个不可达的路径附上一套煞有介事的解释。这个问题在复杂项目里会被放大因为上下文窗口根本装不下所有相关代码模型只能基于片段补全想象。二是推理深度限制。跨五个文件、涉及全局状态更新和复杂锁语义的漏洞模型很难独立还原完整数据流。它擅长的是“局部深挖”而不是“全图通览”。换句话说它像个很聪明但精力有限的初级研究员必须有人帮它缩小范围。三是双向性风险。AI 在防御者手里是审计工具在攻击者手里同样可以成为找洞的引擎。这跟任何通用技术一样本质上是双刃剑。正因如此“在漏洞进入稳定版本之前提前发现并修复”这件事比 AI 本身更值得关注——防御者和攻击者都在用 AI赛跑的胜负取决于谁先把手举起来。5. 用 LLM 做代码审计的实操思路与避坑5.1 一套可抄作业的提示词框架Big Sleep 的团队流程普通人没法直接复刻但“用 LLM 审计一个具体函数”这件事你我现在就可以做。我自己试验过不少次效果比较稳定的提示词框架分四层分享出来供参考。第一层交代身份和任务。不要只说“帮我看看这段代码有没有漏洞”要明确告诉它“你是一名资深安全研究员正在对某个 C 语言项目做漏洞审计目标是找出可被外部输入触发的内存破坏问题”。限定角色能显著降低泛泛而谈的概率。第二层提供上下文和边界。给它目标函数源码、所在文件的关键结构体定义、输入来源说明更重要的是明确告诉它“不要分析整个项目只看这个函数及其直接调用者”。范围不收紧模型很容易开始编故事。第三层给出危险操作清单。列出你想让它重点检查的 sinks比如数组写入、memcpy、指针解引用、内存释放、整数运算、循环边界。这相当于给模型一张“要关注什么”的雷达图。第四层要求结构化输出。让它输出“可疑行号、触发条件、从输入到可疑点的调用路径、建议的验证方式”明确指出“如果认为没有漏洞请直接说没有不要强行凑”。最后这句特别重要能压住一部分幻觉。我自己常用的一个精简模板长这样你可以在此基础上改你是一名资深安全研究员。以下是目标项目中的一个 C 函数源码含所在文件的关键定义。请重点审计该函数及它直接调用的子函数任务如下 1. 找出所有可能导致内存破坏的缺陷包括但不限于越界读写、未初始化访问、重复释放、整数溢出。 2. 对每个候选漏洞列出具体行号、前置条件、从外部可控输入到该位置的完整调用路径。 3. 如果某条路径被某个不可满足的条件阻断请明确指出不要臆想可达性。 4. 没有发现问题时直接回答“未发现”不要为了完成任务强行给出漏洞。 附源码 代码区域这套框架的核心逻辑其实就是把 Big Sleep 的那种“研究员式追问”压缩成了一段可复用的提示词。它不一定每次都能命中真实漏洞但作为人工审计的前置过滤器效率提升非常明显。5.2 AI 说“这里有洞”之后怎么验证AI 输出的候选漏洞百分之百需要人工验证而且验证手段最好跟“AI 的回答”完全独立。我通常按三步走。第一步用带内存检测的编译器重新编译目标源码。C/C 项目开 AddressSanitizerASAN和 UndefinedBehaviorSanitizerUBSAN这是最简单粗暴但有效的手段。你不需要理解完整代码只要构造出 AI 说的触发输入跑起来看 sanitizer 报不报错。第二步复现时一定要把 AI 给的“调用路径”当作线索而不是答案。实际触发过程中用调试器在可疑函数入口打断点逐步确认数据流真的走到了它声称的位置。很多时候你会发现问题出在“AI 以为变量 X 是用户可控的实际上 X 在入口处已经被硬编码成了常量”这种细节上。第三步对照仓库版本和补丁状态。如果目标代码已经修复过就拿修复前后的 diff 对比一下看看 AI 指出的那行是不是恰好是补丁改掉的位置。如果是说明它找的是真问题如果修复后仍然复现那说明它撞到的是另一个分支得重新评估。三个步骤里最容易翻车的是第二步。我见过不少案例AI 给出了一条“看似完整”的调用链里面每个函数名都对但关键前提条件并不成立——比如某个条件判断里藏着一个永不满足的比较整个路径根本是不可达的死代码。这种时候不要怀疑自己的判断直接标记为误报即可。5.3 我踩过的坑和几个小习惯用 LLM 审计代码我踩过不少坑挑几个印象最深的说说。第一个坑提示词不给范围模型开始自由发挥。有次我丢给它一个完整模块的几千行代码想让它“全面审计”结果它产出了一堆“可能存在问题”的提醒看着专业实际要复现时几乎全指向我自己都不知道哪来的函数。后来我改成单个函数加直接调用者效果立刻好了很多。范围控制不是限制是引导。第二个坑把“代码风格问题”当成漏洞。模型会说“这里没有检查返回值可能导致错误”但检查了返回值也只是日志变清晰根本不会造成内存破坏。审计目标是漏洞不是代码质量。一定要在提示词里把漏洞类型限定在内存安全相关范畴否则噪音会淹没信号。第三个坑只信一次回答没有交叉验证。现在我会故意把同样的目标函数用两种方式各问一次一种让它找“外部输入到危险操作的路径”一种让它从“危险操作反向找调用者”。两次回答的交叉点往往更可信。这个思路也是受 Big Sleep 团队公开方法启发不依赖模型单次推理而是用任务拆分让不同视角互相印证。另外还有个小习惯每次让 AI 审计前先自己跑一百次 fuzzer。原因很简单如果这个函数连 fuzzer 都能撞崩溃那 AI 的加入只是锦上添花真正的价值在于 fuzzer 撞不出来、语义层面才能看出来的问题。把 AI 用在 fuzzer 的盲区上投入产出比最高。最后再分享一个我自己的观察AI 在代码安全这件事上的发展速度比大多数人的预期要快。两年前我们聊起“让 AI 找漏洞”讨论的还是能不能复现基础缓冲区溢出现在 Big Sleep 已经能在 SQLite 这种被翻来覆去测过的项目里挖出新洞并且走完从发现到修复的完整闭环。我自己从这轮实验里得到的最关键体会是技术本身固然重要但更重要的其实是任务设计——把开放问题拆成可验证的窄问题让人和 AI 各管一段验证交给工具判断交给人。这套思路不仅适用于挖洞也适用于任何想用大模型做专业判断的场景。往后我大概率会把类似流程固化到日常代码审计里毕竟漏洞不会等我们准备好再出现。
