最近安全圈最火的一条消息莫过于“20年Linux漏洞被Claude5.0 90分钟攻破”。这个标题的冲击力很强我在技术社区里看到不少讨论有人觉得是炒作有人焦虑“人类安全研究员是不是要失业了”也有人立刻拿它当论据去跟老板要预算。作为一个常年泡在漏洞挖掘和代码审计一线的从业者我的第一反应其实是不管这个事件里有多少演绎成分它背后指向的技术路径——用大模型做语义级代码分析、自动追踪污点链路、辅助构建PoC——是实打实正在发生的趋势。这篇文章我不打算复述新闻而是想从这次事件出发把“AI到底是靠什么把老漏洞翻出来的”这件事讲透再给出一套我自己实践过、能直接复用的AI辅助挖洞工作流。不管你是安全研究员、运维工程师还是刚入行的新人读完应该都能理解这类工具现在能做什么、做不到什么以及怎么把它变成自己的生产力。1. 先捋清楚这个“20年的洞”到底是怎么被翻出来的1.1 一个典型“老漏洞”的画像能存活20年的漏洞通常不是那种放在门口一眼就能看见的问题而是藏在“大家都以为没事”的角落里。我做了这么多年代码审计最深的体会就是历史代码里的洞往往有几个共同特征。第一代码够老。20年前的C代码风格和现在完全不一样。那时候没有如今这么严格的代码规范开发者喜欢用各种“技巧性”写法——指针用得飞起内存分配和释放散落在多个分支里错误处理路径常常不完整。这种代码今天去看可读性非常差甚至很多地方连注释都没有维护者自己都不一定记得当初为什么这么写。第二路径够深。真正危险的漏洞很少在表层逻辑里往往藏在一个看起来无害的函数背后。比如某个工具库在处理特定格式输入时先把数据拷贝到局部缓冲区再根据另一个字段决定是否越界操作整个触发链路跨了三四个文件、五六个函数。人工审计的时候如果在第一层没发现问题很容易就跳过去了。第三触发条件够偏。很多老漏洞不是“必现”的而是需要非常特殊的输入组合。这类路径日常没人去碰自然也不会在常规测试里暴露。我记得之前看过一个案例分析一个存在于某文件系统解析工具里的整数溢出触发条件是“文件名长度恰好为某个特殊值”这种边界条件靠人肉去想真的很难覆盖全。这次新闻里的“20年漏洞”大概率就是这种画像老组件、深路径、偏触发条件。三个因素叠加导致它在人类维护者的视野里“隐形”了20年。1.2 为什么人工审计这么多年都没发现不是说人类安全研究员不行而是人类的工作模式存在结构性天花板。一个全职做代码审计的研究员一天能精读多少行代码说实话高质量地读500到1000行已经非常累了因为你要同时跟踪变量生命周期、调用上下文、锁的获取顺序、错误路径的分支走向。而一个Linux发行版光内核源码就有几千万行整个核心工具链加起来更是天量。就算把所有安全研究员的时间都堆上去也只能对最核心、最常用的部分做深度覆盖。更麻烦的是人类有注意力盲区。读代码久了会形成“路径依赖”——你熟悉了代码的正常逻辑流就很容易不自觉地把异常分支当成“不太重要”的部分略过。恰恰很多漏洞就藏在异常处理里分配失败后没有释放、校验失败后继续往下走、截断之后忘记补终止符。我自己的经验是审计时最容易漏掉的往往不是主逻辑而是那几个“出错了会怎样”的分支。还有一个非常现实的因素维护者对历史代码有心理惯性。一段代码跑了十几年没出问题大家默认它就是安全的。即使有人提出要重构或审计优先级也排得很靠后——毕竟“没坏就别修”是工程界的铁律。这种惯性本质上给了漏洞充分的“潜伏期”。1.3 AI让漏洞挖掘的“搜索空间”第一次被压缩理解了人类审计的瓶颈就明白AI的价值在哪了——它不是一个“更快的读代码机器人”而是一种能把搜索空间大幅压缩的分析范式。传统上我们找漏洞的方式大致分两类。一类是静态分析靠规则匹配危险模式比如strcpy、memcpy附近是否校验了长度优点是覆盖面广缺点是有海量误报。另一类是动态fuzzing靠构造输入去撞崩溃优点是能找到能真实触发的崩溃点缺点是覆盖路径有限很多深层逻辑根本跑不到。大模型在这里的角色完全不同。它不是按固定规则扫也不靠随机输入撞而是理解代码语义之后做推断——就像让一个读过整份源码、脑子能同时记住几十个函数上下文的高级研究员在很短时间里把可疑链路全部梳理一遍。它看到的不是“某一行调用了memcpy”而是“某个用户可控的输入经过了三层转换最终可能影响memcpy的长度参数”。这种语义层的关联能力才是它能发现“20年老洞”的根本原因。我把这理解成以前我们是用“显微镜”一格一格找现在是用“雷达”先发现目标再用显微镜确认。两者不是替代关系而是不同维度的效率提升。2. 90分钟攻破背后是AI对代码分析范式的改变2.1 从“逐行读代码”到“语义级跨函数追踪”我经常拿这个类比来解释AI分析代码的方式人类读代码是“串行”的你得一行一行往下看看到函数A调用函数B就得跳去读B读完B再跳回来。遇到调用层次深的脑子里的栈很容易乱——读到第五层可能已经忘了第一层的变量叫什么了。大模型读代码是“并行”的。只要你把代码片段喂给它它可以同时“记住”所有层级的变量名、函数签名、调用关系并在回答时交叉引用。虽然受限于上下文窗口它没法一次读完整套Linux内核但通过合理的分段和索引它可以围绕一个目标函数把它的所有调用者、被调用者、相关数据流一次性拉出来分析。这就带来一个本质变化跨函数追踪的成本被急剧拉低。以前人工追踪一条从用户输入到危险函数的链路可能要花一两天。AI可以在一次对话里把这条链路上的每个节点都过一遍并指出哪个节点的约束条件可能被绕过。2.2 危险函数雷达AI如何快速锁定可疑点很多读者可能好奇AI是怎么在那么多代码里“盯上”某个函数的从我实际的使用体验来看有效的做法不是让AI“通读全文找漏洞”而是给它一个明确的“雷达范围”。你可以告诉它重点审查所有与外部输入交互的入口如网络协议解析、文件格式解析、命令行参数处理对调用过内存操作函数如memcpy、strcpy、sprintf、memmove的位置做一次体检特别关注存在长度计算、索引计算、循环边界处理的地方。AI拿到这些约束后会先做一轮“预筛”把符合条件的位置列出来再逐个分析这些位置是否存在真实的利用可能。这个“预筛”能力看起来简单实际非常关键——它把天量的代码缩小到了几处明确的可疑点分析成本直接降低了几个量级。我在自己的项目里试过类似工作流把一段两百行的C函数喂给AI让它找出“长度参数来源不可控”的位置它的回答往往直接精确到行号还附带触发思路。这种精度至少已经超过了大多数初级代码审计工具接近中级研究员的水平。2.3 污点链路还原输入是怎么一路流到内存破坏点的如果说锁定可疑点是第一步那“污点分析”就是这次AI攻破老漏洞的核心能力卖点。所谓污点分析大白话说就是找到一条从“我能控制的数据”到“可能出事的操作”的完整路径。比如用户发送的网络数据包是个“污点源”memcpy的目标地址和长度是“危险汇点”那么污点分析要回答的问题就是“用户数据到底能不能控制这个长度参数中间有没有被过滤或校验”以前这类分析需要借助专门的静态分析工具配置复杂、误报率高而且对跨函数场景的支持往往不理想。AI让我最惊喜的地方是它能“理解”中间那些转换逻辑。举个例子如果一段代码把用户输入的字符串先做了base64解码又提取出其中某几个字节拼成一个整数再拿这个整数当长度参数去分配内存——传统静态工具很难跟上这层转换AI却可以。它会一步步推导给你看“这里解码后这个字节被当成了长度的高8位所以理论上你可以构造一个0xFFFF长度的值”。这种对“中间转换逻辑”的理解能力正是AI挖洞与传统工具的最大分水岭。老漏洞能存活20年本质上就是因为中间转换逻辑太绕人类没绕过来传统工具又绕不动。而AI恰好补上了这个短板。3. 实战推演用AI辅助复现一次“老洞速挖”这一节我用自己的真实操作经验基于这类事件的通用模式做一次推演。下面描述的是一个“假设案例”但流程、命令和思路都来自我的实操积累可以直接复用。3.1 环境准备一个可控的靶标组件想练习AI辅助挖洞第一步是找一个合适的靶标。我的建议是不要一上来就去啃Linux内核那难度太高很容易挫败。最适合练手的是带历史包袱的开源C工具库尤其是那些还在被广泛依赖、但很少有人系统审计的组件。具体选择标准有三条用C语言编写包含明显的文件解析或网络协议处理逻辑至少有10年以上的历史能看出老代码的痕迹对外部输入有真实处理入口而不是纯内部逻辑。准备好靶标后落实分析环境。建议用一台Linux虚拟机装好gcc、gdb、valgrind以及一个基础的fuzzing工具比如AFL后面验证PoC或者跑崩溃样本都用得上。我习惯把源码下载后先正常编译一遍确认能跑通再开始喂给AI做分析。3.2 让AI描述漏洞触发链从输入到越界核心环节来了。你要做的不是直接问“哪里有漏洞”而是引导AI做一次结构化的数据流分析。我的标准做法是把目标组件里负责“读取输入”和“处理输入”的核心函数提取出来按调用关系排列后丢给AI然后给出这样一段提示请分析以下代码路径中的数据流。假设外部输入完全可控重点关注1输入长度是否在校验后被后续逻辑重用2是否存在整数溢出可能3内存拷贝的长度参数是否可能大于目标缓冲区。输出格式列出每条可疑链路注明涉及函数、行号、触发条件以及你认为可利用性最高的前三条。AI给出的分析结果通常会包含几个可疑点其中至少有一个会指向“长度参数存在约束绕过可能”。我在一个类似的文件解析工具上跑这个流程时AI指出了一个我在人工审计时忽略掉的细节某个长度字段在函数A里被校验过但该校验只发生在某个分支下另一个分支直接跳过了校验就进入后续拷贝逻辑。这种校验覆盖不完整的问题恰好就是经典漏洞的温床。3.3 从线索到PoC复现过程中的关键修正拿到AI的分析线索之后距离“攻破”还差最关键的一步把理论上的触发条件变成实际会崩溃的PoC。这一步没有捷径必须手动构造输入样本。我的流程是这样根据AI指出的触发条件识别输入文件或网络包中哪个字段是“可控长度”计算这个字段的取值范围找到能触发整数溢出或越界的一个值构造最小样本在gdb里跑观察是否真的出现SIGSEGV或堆破坏。这个过程中最常见的情况是第一次构造的样本根本不会崩溃。原因往往是AI没充分考虑某些隐含约束比如某个循环其实会把长度限制在一个范围内或者某个条件分支只有在特定标志位置位时才可进入。我遇到这种情况时会把这个反馈再丢回给AI让它重新推导“我构造了X输入预期触发崩溃但没有。这是gdb的调用栈贴上来请分析哪里对不上。”AI通常能根据实际反馈修正之前的判断指出需要同时满足的另一项条件。这种“AI推测、人工构造、反馈校正”的循环往往要迭代2到4轮。每一轮都能把触发条件收得更紧最终得到一个稳定的崩溃样本。我从个人经验总结这个循环的收敛速度就是AI挖洞工具的核心性能指标。3.4 验证结果的正确姿势看到崩溃不等于获得漏洞还需要做验证和定性。我一直强调这个原则崩溃样本只是门票能证明“可控”才是漏洞。拿到崩溃点之后要看三件事崩溃位置是否位于目标组件的内存拷贝/写入操作中写入长度是否真的由外部输入控制而非固定值或无关变量能否进一步控制写入内容或跳转方向还是只能造成拒绝服务。验证过程中gdb是不可或缺的。我在崩溃处下断点检查寄存器里是否出现了我构造的数据以及越界写入的目标地址偏移是否与输入字段相关。如果写入长度和内容都能精确操控那么这不止是一个崩溃型漏洞很可能是一个可控的内存破坏漏洞——在真实场景下意味着潜在的命令执行或权限提升。确认这些之后我会再把完整的崩溃信息和验证结果喂给AI让它帮忙评估漏洞等级和受影响版本范围。这里有个心得AI对漏洞严重性分级的能力是可靠的但你对“可利用性”的判断一定得自己确认别全信它。毕竟它看不到运行时环境里的具体防护措施。4. AI挖洞不是玄学工具选型与Prompt工程4.1 三个派别纯大模型、FuzzingLLM、Agent式自主挖掘现在市面上号称“AI挖洞”的方案不少我梳理下来大致分三派定位完全不同。第一派是纯大模型分析。就是像我前面演示的那样把代码喂给Claude、GPT这类模型靠对话分析找线索。优点是灵活、上手快不依赖特定框架任何有AI接口的人都能用缺点是需要人持续介入不能全自动而且上下文窗口有限分析超大项目时要自己管理分段。第二派是FuzzingLLM。思路是让LLM来辅助生成fuzzing的种子输入、变异策略或者分析fuzzing崩溃样本的根因。典型的项目比如谷歌的OSS-Fuzz里整合的一些AI辅助方案。这一派的好处是继承了fuzzing“能真实触发”的可靠性不依赖AI完全理解代码劣势是搭建成本高需要同时维护fuzzing环境和LLM调用链路。第三派是Agent式自主挖掘。让AI像人一样自主执行“读代码—猜测漏洞—构造输入—运行验证—分析失败—换个方向再来”的闭环。这个目前还在早期主要受限于模型推理的稳定性和运行时授权边界。这次新闻里“Claude5.0 90分钟攻破”从技术形态上更接近这一派。对个人研究者我的建议是先把第一派练熟再去了解第二派。Agent式的坑还很多普通人现阶段很难跑通不必盲目追。4.2 实操中的Prompt设计技巧目标描述、约束条件、输出格式很多人在AI辅助审计上“跑不出来”问题不在AI而在问法。我把踩过几次坑之后沉淀下来的Prompt设计要点总结成三条第一目标描述要具体禁用“找漏洞”这种空泛词。你越是说“请找出这段代码的漏洞”AI越容易给你一堆模板化的“可能存在风险”毫无可操作性。正确的做法是给出确切的安全属性要求比如“检查是否存在整数溢出导致的内存越界写”。你给的检查维度越具体AI的分析越能深入。第二约束条件要说透特别是“假设外部输入完全可控”。这很关键——模糊措辞会让AI自行猜测攻击者控制能力导致它判断的“可利用性”漂移。明确声明“所有从文件/网络读取的数据都视为攻击者可控”可以让它把分析重心全部放在“数据如何流到危险点”而不是纠结“这个输入真实场景下能不能被用户碰到”。第三输出格式要固定建议直接要求它分条列链路。我的习惯是要求AI按“函数名—行号—输入来源—危险操作—触发条件—可利用性评估”六个字段输出。格式化输出有两个好处一是逼AI把模糊的“这里可能有问题”落到实处方便你逐一验证二是你贴回反馈时AI能基于同一套格式高效迭代不会答非所问。4.3 一套可复用的AI辅助审计工作流讲完技巧给一个可直接落地的工作流。这是我当前在项目里实际使用的主流程你照着搭就能用。模块化喂码把目标代码按功能模块切分每个模块限制在300到500行。每次只喂一个模块确保模型上下文足够聚焦。关联模块之间通过“摘要指针”的方式传递信息——先让AI总结A模块的行为再连同B模块一起让它分析跨模块数据流。首轮全景扫描向AI发起“危险函数雷达”指令要求列出模块内所有涉及内存操作、索引计算、长度转换的可疑点。逐点深挖对每个可疑点要求AI展开做污点分析。提示语参照我给的格式输出完整链路。人工逆向验证拿到链路后不理解的部分直接在源码里跳过去读确认AI的推导是否与真实逻辑一致。这一步别省AI会“错得起”但你系统里跑的是真实代码误差必须人来兜底。反馈闭环把验证不一致之处贴回AI要求它修正推导。循环直到推理与源码行为一致。动态确认对保留的可疑链路用gdb或fuzzing做动态验证跑出崩溃样本后完成定性。这套流程的参数配置上我一般设置每轮AI分析输出至少包含5个可疑点3条完整链路避免它只挑一个方向跑到黑。实测下来对中等复杂度的C库一轮完整审计通常能锁定1到2条值得深入的可疑链路后续再靠人工和动态验证收敛。5. 说实话AI挖洞现在还得“人机协同”5.1 AI最容易翻车的三类场景如果你按上面的流程实操过就会知道AI远没有宣传里那么“神”。以我的经验它在三类场景下特别容易翻车。第一类是状态机逻辑。凡是依赖复杂全局状态、多阶段初始化、锁顺序的场景AI经常分析到一半就把状态搞混。它记不住“这个标志位是在A阶段置位、B阶段才被检查”这类时序信息给出的结论很容易与真实执行路径矛盾。第二类是回调与间接调用。如果代码里大量使用函数指针、注册回调机制AI往往只能看到“调用了某个函数指针”但无法可靠推断这个指针在运行时具体指到哪。这条链一旦断掉污点分析就失效了。第三类是并发相关。涉及线程同步、race condition的问题AI尤其容易给出“看起来很合理但完全错误”的分析。我目前还没见过哪个模型能在不给详细线程模型的情况下稳定推断出竞态条件的具体触发路径。这三个场景有个共同点都对“运行时动态信息”有强依赖而AI在静态条件下只能靠猜。所以判断一段代码适不适合用AI挖先看它是否大量涉及这三类逻辑。5.2 误报、幻觉与上下文窗口的硬约束再聊几个使用AI挖洞时绕不开的“力场”问题。首先是误报率高。AI在“疑似风险”的判断上是偏激进的宁多勿漏。这跟传统工具有点像但表达方式更“自信”——它会用确定的语气告诉你“这里存在整数溢出”结果你跑过去一看前面早就有一个隐蔽的unsigned char强制转换把值限制住了。所以任何AI结论未经人工确认前都只能算“线索”不算“发现”。其次是幻觉。这是大模型的老毛病。尤其是在分析超长代码时AI会“编造”一些不存在的行为——比如引用某个实际上没有的变量赋值或者编一条实际不存在的调用路径。我踩过的坑是它言之凿凿地告诉我“该函数在行1624处对缓冲区做了越界写”我过去发现行1624根本不在那个函数里。应对办法只有一个对每一条它给的结论都回原始代码里去核实不核实不采信。最后是上下文窗口的硬约束。即使是最新一代模型窗口扩大了不少但真正有意义的有效分析窗口远小于标称值。塞太多代码进去模型会“遗忘”早期的关键约束导致分析前后矛盾。我的经验是单次分析控制在500行以内超过就分段每段分析先让模型输出摘要再在下一轮把摘要作为上下文一起带入。这招虽然笨但稳。5.3 什么项目适合AI挖、什么不适合根据自己的实践我大致划分了适合与不适合的边界。适合用AI辅助的老旧的C/C解析类组件文件格式、网络协议尤其是路径深、变量名晦涩的那种有明显“输入—处理—输出”结构的命令行工具需要对历史漏洞进行模式匹配分析找出“跟CVE-2023-xxxxx类似的问题”。不太适合的依赖大量运行时状态的复杂系统比如内核调度器业务逻辑漏洞权限绕过、越权访问这类问题高度依赖业务语义AI对“业务里什么算越权”理解有限强混淆、强加密的代码AI会直接迷失。简单说凡是以“数据如何到达危险点”为核心的问题AI的辅助价值最大凡是“设计意图边界在哪”的问题AI目前还帮不上太大忙。6. 从“AI攻破老漏洞”看Linux安全生态的下一步6.1 维护者视角修复窗口与安全公告的节奏这次事件真正让Linux维护者感到压力的不是“有个洞被发现了”而是发现速度与修复速度的倒挂。以前一个漏洞从披露到出利用通常有数周甚至数月的窗口期。维护者可以利用这段时间发公告、修补丁、推动下游合入。但当AI把发现时间压缩到90分钟留给修复的时间就极其有限。而且AI能发现一个理论上就能以相同成本发现第二个、第三个——传统的“发现一个修一个”的被动应急模式很可能被这种批量产出的发现速度所击穿。我接触的一些开源维护者已经在调整做法一是加大对历史代码的主动AI审计争取“自己先发现”二是建立更快的安全响应流程把从patch到发布的时间再压缩三是对AI可访问的代码仓库做更细粒度的发布控制减少预发布代码暴露面。6.2 企业安全团队该不该引入AI安全审计这段时间不止一个客户问我团队要不要采购AI安全审计工具。我的观点很明确要引入但先想清楚定位。如果是自研代码的发布前审计AI辅助的价值非常直接——它能用很低成本覆盖大规模代码库找出人工容易遗漏的边缘路径。这个场景下AI是“增量”而不是“替代”建议以“AI初筛人工复核”的方式嵌入现有SDLC流程。如果是对外服务或开源组件的漏洞监控AI的价值就没那么直接因为你要先有目标代码库还要处理大量误报跟进。我更建议先把内部存量系统跑一轮AI审计建立历史基线再决定是否常态化监控。无论哪种方式都建议设立专用预算和明确KPI比如“每月完成X万行代码审计”“高危发现复现率不低于Y%”。没有明确目标的AI安全工具采购大概率会变成一堆“演示很酷但没人用”的摆设。6.3 白帽社区的机遇与内卷对白帽研究员和SRC、众测从业者来说AI挖洞的普及是一把双刃剑。机遇在于它把漏洞挖掘的入门门槛拉低了。以前想挖出有价值的漏洞需要极强的代码能力和耐心现在借助AI辅助一个懂安全原理但代码经验有限的年轻人也能在引导下完成从线索到PoC的全流程。这会带来一波“漏洞产量红利”尤其在企业SRC和漏洞赏金平台条件合适的话短期内确实有机会“挖到钱”。挑战在于同一批漏洞被AI同时发现的可能性大增。以前一个漏洞可以靠信息差“独享”几个月的价值现在多个研究者用同一套AI工具扫同一个目标很容易撞车。撞车意味着白帽提交的漏洞失去稀缺性赏金会显著缩水甚至无效。我在社区里的观察是纯粹靠“扫描式”找洞的空间在快速收窄能靠业务理解力找到“AI找不到的逻辑洞”的人价值反而在上升。说到底AI让常规漏洞变便宜了但让高级漏洞研究员的判断力变得更值钱。写到这里我特别想分享一个自己最近的实操感受我花了四年时间一直想在一段老代码里找到可利用的溢出链一直没突破。上个月我抱着试试看的心态把这段代码拆成三段用AI做了一次系统性污点分析它在一个我从未关注的错误处理分支里指出了一条隐藏的长度参数旁路。顺着这条线索我当天晚上就跑出了崩溃样本。这次经历让我更加确定AI不会取代安全研究员但它会重新定义“研究员”这个角色——你不再只是那个坐在代码前一行行读的人而是那个知道该问什么问题、该如何验证答案、如何把线索变成利用的人。工具变了门槛变了真正的核心竞争力始终是判断力。