智能漏洞挖掘实战指南：超越传统指令的自动化方法
信息过载是当代安全从业者的核心困境。问题不在于信息匮乏，而在于缺乏一套精准的信息筛选与处理机制。在安全审计领域，这一挑战尤为突出：我们面对的是海量代码，真正的瓶颈在于如何引导AI进行高效、聚焦的分析。
近期，安全领域的一个实践趋势日益清晰：利用大语言模型（LLM）挖掘代码漏洞已从概念验证步入实战产出阶段。有研究者在两个月内，仅凭LLM驱动，便在Parse Server、HonoJS、ElysiaJS等主流开源项目中成功识别出30余个有效漏洞，全程未依赖传统人工审计。
然而，这里存在一个关键的反直觉洞见：要让AI在安全审计中发挥最大效能，恰恰需要避免复杂的流程设计和冗长的指令。
为什么“找出所有漏洞”这条路走不通
面对一个新代码库，许多人的第一反应是向AI工具发出宽泛指令：“找出这个代码库里所有的漏洞。”
这种指令几乎必然失败，原因有二。
第一，缺乏明确的威胁模型。AI无法理解你所关注的“影响”具体指什么。它可能尝试自行推导威胁模型，但实际测试表明，其推导结果通常不准确或质量低下。在没有明确定义信任边界、攻击者能力和前置条件的情况下，你得到的只会是一份冗长、泛泛的、类似CWE分类的可能性列表，难以区分真正的高风险项。
第二，诱发“广度优先式幻觉”。宽泛的指令导致宽泛的响应。AI会进行模式匹配，寻找常见的漏洞类型，即使这些漏洞在当前的代码上下文中根本不可能被触发。结果就是你浪费大量时间审查攻击者无法触及的代码路径中的“理论漏洞”。
研究表明，随着上下文窗口内容的增加，模型提取关键细节的可靠性会下降，这种现象被称为“上下文腐化”。即便新增内容是相关的，模型性能也会随着上下文长度增加而变得不稳定。
安全审计是这一问题的典型场景。真正的漏洞往往是微小的、违反逻辑的细节，潜藏于数千行正常代码之中。模型表现出明显的“首因/近因效应”——当关键信息位于上下文开头或结尾时，其表现尚可；一旦关键信息被埋没在中间，其识别能力便急剧下降。
真正管用的极简方法
既然宽泛指令无效，正确的方法是什么？
在让LLM审计代码之前，应首先像人类安全专家一样，尝试识别威胁模型。这一步骤本身也可由LLM辅助完成。
具体操作是：先梳理项目历史上披露过的CVE，然后基于这些CVE描述，提示LLM构建一个威胁模型，推演出与该历史漏洞模式相符的潜在漏洞类型。
例如，若历史CVE多与堆溢出、栈溢出、内存破坏相关，LLM便会尝试为这类内存安全漏洞构建威胁模型——因为这些已被项目方确认为有效攻击路径。
接下来，将这份威胁模型文档输入AI，指示其找出模型中的“安全不变量”，或尝试定位修复这些漏洞的代码提交，并分析是否存在绕过可能。这种方法比给出一个模糊指令更有可能发现新的漏洞。
在这个案例中，你所构建的极简“支架”就是威胁模型。无需创建复杂的指令文件，也无需编排繁琐的流程。你只是创建了一个威胁模型，交给LLM，后者便会在代码库中进行深度探索，寻找符合该威胁模型的模式。
完成对历史同类漏洞的挖掘后，可以转向其他方法。识别入口点：如HTTP路由、RPC处理程序、消息消费者、CLI入口点、定时任务。识别信任边界：如浏览器到服务器、服务到服务、插件到宿主、沙盒到特权环境。识别高风险操作：如反序列化、模板渲染、原生绑定、授权检查、解析不可信输入。明确攻击者-受害者模型：例如，目标是寻找可由远程未认证用户、远程认证的低权限用户，还是跨租户用户触发的漏洞。
正是这种轻量级的结构，提升了分析的“信噪比”，同时避免了撑爆上下文窗口。
威胁建模，本质上是安全审计的终极压缩算法。
案例：Parse Server是怎么被挖出四个漏洞的
Parse Server是一个开源后端框架。其文档声称支持一种“只读主密钥”，该密钥应授予对所有数据的读取权限，但拒绝所有写操作。
在提示LLM进行审计之前，研究者首先梳理了Parse Server历史上披露的CVE。过去的公告揭示了一个反复出现的模式：授权执行失败——权限检查存在，但不完整，或在各路由处理程序中应用不一致。将这些CVE描述输入LLM，让其基于历史生成威胁模型，推演可能的漏洞类型。模型将授权边界执行识别为主要风险类别，这符合Parse Server采用多种密钥类型对应不同权限级别的架构特点。
这一威胁模型使得“只读主密钥”这一权限边界变得极具分析价值。核心声明很简单：一种密钥类型的能力应严格弱于另一种。研究者引导LLM聚焦于此边界，让其探索不同密钥类型如何与授权层交互，代码对权限分离做了哪些假设，以及这些假设可能在何处被打破。
LLM返回了一份攻击面地图，突出了一个关键模式：多个路由处理程序仅通过isMaster进行访问控制，却从未检查isReadOnly。
这就是明确的信号。研究者随后发出更聚焦的指令：枚举每一个展示此模式的处理程序，并追踪只读凭证是否可能通过其中任何一个路径执行写操作或改变系统状态。
最终发现的四个漏洞中，有三个源于这一根本原因。
为什么这能成功
所有这些成功的审计都未使用庞大的检查清单、20页的指令支架或全面的安全框架。每一次都始于一个简短的威胁模型，通常一句话即可概括，再配上一个直接映射到信任边界或关键安全操作的、高度聚焦的代码切片。支架极其简单，但方向正确。它精准地指引LLM去测试哪个安全不变量，以及去哪里寻找违反该不变量的证据。
好的支架是一页纸的威胁模型、一份核心功能列表，以及一组如“只有管理员能调用X”、“JWT签发者必须是Y”这样的具体不变量。
坏的支架则是20页的Agent.md，包含所有策略和风格指南；一个庞大的Skill.md库，预加载了所有安全清单；以及每轮对话都重复的样板指令。如果你的支架变成了“草垛”，漏洞就成了“针”。而关于长上下文性能的证据表明，草垛越大，找到针的难度就越高。
应将审计任务拆分为与真实攻击面匹配的“薄切片”。选择一个切片，例如认证、会话管理、请求解析、文件上传、反序列化、沙箱边界或插件边界。让模型将该切片的入口点映射到敏感接收器。要求提供确凿证据——精确的调用链、守卫条件、不变量，以及哪些输入是攻击者可控的。
一个实用的经验法则是：将少于10%的上下文预算用于稳定的支架（威胁模型和不变量），60-80%用于聚焦特定切片的审计上下文，20-30%用于验证循环，以证明、复现、精简和修补漏洞。
几个实用的提问技巧
找到正确的代码切片并建立威胁模型只是第一步。一旦进入分析阶段，向LLM提问的方式将直接决定你得到的是泛泛的观察列表，还是实际可利用的发现。
宣称漏洞存在。这是最有效的单一技巧。当你告诉LLM“这个函数肯定存在漏洞，至少有2到3个安全问题”时，相比询问“这个函数有漏洞吗？”，其分析质量会显著提升。原因在于：LLM有强烈的默认倾向去求同和确认。当你问“这有漏洞吗？”，模型最容易走的路径是回答“这看起来总体安全，可能存在一些小问题”。而当你宣称漏洞存在，你就翻转了模型的优化目标。它不再评估是否存在漏洞，而是转而搜索那些被告知肯定存在的漏洞证据。
要利用方法，不要评估。与其问“这个输入验证足够吗？”，不如问“编写一个能绕过此输入验证的概念验证请求”。这会迫使模型产出具体的、可测试的输出，而非用定性评估来含糊其辞。
将模型定位为对手，而非审计员。“你是一个正在审计这段代码的安全审计员”与“你是一个红队操作员，被雇佣来攻破这个应用”，这两种定位会产生截然不同的输出。审计员框架让模型偏向于完整性和彻底性，但容易产生一长串低信噪比的观察列表。红队框架则让模型偏向于影响力和实际可利用性。
分解为不变量，然后逐个击破。让LLM首先列出函数为保持正确性所依赖的每一个不变量、假设或前提条件，然后要求它逐一检查每个条件是否在实际代码中成立。这种两步分解法之所以有效，是因为它将枚举任务与评估任务分离开来，降低了认知负荷。
写在最后
信息过载是当代安全从业者的核心困境。问题不在于信息匮乏，而在于缺乏一套精准的信息筛选与处理机制。在安全审计领域，这一挑战尤为突出：我们面对的是海量代码，真正的瓶颈在于如何引导AI进行高效、聚焦的分析。
归根结底，利用AI挖掘漏洞的关键，不在于向模型灌输多少指令，而在于你为它建立了何种“心智模型”。一个简洁、精准的威胁模型，其价值远胜于二十页的通用检查清单。让工具负责“高效执行”，让人负责“战略思考”——这才是人机协作的最佳模式。