随着软件规模的不断扩大和复杂度的持续提升，传统的代码审计方法正面临诸多挑战，包括效率低下、人工成本高昂以及潜在漏洞的遗漏等问题。在此背景下，人工智能（AI）技术的迅猛发展为代码审计提供了全新的解决方案和思路。
当前业界在AI驱动代码审计领域的研究和实践正在蓬勃发展，各种思路和技术路径不断涌现。本文将持续跟踪业界在AI驱动代码审计领域的最新实现思路，探讨其技术优势、应用场景以及面临的挑战，并展望未来的发展趋势。目的是通过系统梳理这一领域的技术进展，希望能为相关研究和实践提供有价值的参考。
| AI 驱动代码审计文章 | 发布时间/作者 | 核心思想梳理 |
|---|---|---|
| 使用llm来辅助静态扫描的人工审计 | 20240426，先知 apsry | 利用 Semgrep 和 CodeQL 进行初步代码扫描，然后通过 LLM 辅助确认审计结果，前期放宽 SAST 对 Sink 的判断规则，将更多的潜在漏洞链路交给 LLM 去分析，以降低漏报。 |
| 全球首个安全代码审计AI-CodeArgus | 20240716，广州朋克智能科技有限公司 | 通过多角色的 Agent 智能体协同（软件分析师、软件工程师、安全工程师），完整项目代码静态分析、代码理解、安全审计，使其能够支持包含逻辑类的多种漏洞的审计。 |
| vulnhuntr-first-0-day-vulnerabilities | 20241019，Protect AI | 1. 借助 Jedi 库完成 AST 解析，将代码分解成小的、可管理的块，通过精准化提取代码段，尽可能减少传输给 LLM 的代码段长度，使得 LLM 对漏洞的判断更为精准； 2. 通过 LLM 自动循环分析代码，不断请求污点分析链路上所需的新的上下文（函数或类），直至确定漏洞或排除可能性，解决了 SAST 痛点：难以精准判断所需上下文； 3. 指出 RAG 和微调的实验效果并不好，并判断未来这种精准化代码传递会保持价值。 |
| 大模型应用实践1：AI助力Code Review安全漏洞发现 | 20241127，腾讯啄木鸟代码安全团队 | 指出了大模型在代码审计上分析代码功能、跟踪数据流上的可行性，以及如何借助 COT、结构化输出等方式规范大模型的推理，最后总结了一些局限性和解决方法，比如可借鉴 MoE 架构用多个子模型解决过长上下文导致失焦、采用多模型投票方案解决幻觉问题 |
| 渗透测试：基于LLM增强的越权检测工具实践 | 20241206，中信建投金融科技+ | 常见的越权漏洞检测，通过采用关键词判断 http 响应是难以覆盖完全的，而 LLM 出色的自然语言泛化能力能够做出近乎无错的分类，因此作者把主要 LLM 应用于负责对 HTTP 请求响应进行语义解析 |
| AI猎手：我们用大模型挖到了0day漏洞！ | 20250103，腾讯啄木鸟代码安全团队 | 猜测是腾讯安全团队借鉴 Vulnhuntr 项目，进行二次开发，实现了对 Java 源代码项目的 AST 解析后，借助 LLM 分析污点链路上需要提取的上下文信息。 |
| LLM 提高 SAST 的代审效率的思考方向 | 20250214，A2Cai | 分析了 LLM 在代码审计上的局限性，提出了构造 COT 的参考：1）确定是否存在参数传递的全局过滤；2）从污点函数到入口参数传递，反向分析数据的变化，记录各个函数的具体实现，分析出函数调用的树，让 LLM 分析代码的时候不依赖于变量名称，而是更多在代码逻辑上进行分析； |
| 本地化 AI 审计工具落地小试牛刀 | 20250218，知道创宇 404 实验室 @wh0am1i | 借助 AI Agent 开源开发框架** llama_index**，实现让 AI Agent 自动调用 codeql 分析指定的源代码目录，并让 LLM 分析 codeql 的扫描结果。 |
| 基于污点分析的 AI 自动化漏洞挖掘尝试 | 20250220，知道创宇 404 实验室@longofo | 核心设计思路：先逆向找 sink 到 source 的链路，再用 AI 做 source 到 sink 的正向污点分析判断链路连通性。V1 版本适用于常规漏洞挖掘，尝试设计 V2 版本查找反序列化利用链，发现效果不佳，意识到自己可能在做一个对标 codeql 的东西…… |
| 从人工困局到智能破局 - 大模型在代码安全审计的探索与实践 | 20250220，腾讯云鼎实验室 | 设计了 Multi-Agent 协同挖掘 0day，分别用于：基于文件粒度对开源框架源码进行全量扫描，识别的 Source/Sink（用了增强模型）--> 进行函数代码识别提取 --> 对几千个使用该框架的仓库进行代码安全审计，进行污点链路分析，以此挖掘出 4 个 0day 漏洞。 |
| 白盒 + LLM漏洞挖掘的探索和实践 | 20250321，字节无恒实验室苏忠富 | 作者分析了传统的依赖正则进行自动化白盒审计逻辑漏洞的难点，同时指出了 LLM 倾向报告存在漏洞的现象，建议通过将复杂任务拆分为适合 LLM 的原子任务来降低幻觉，最后给出了他们在 LLM 驱动的逻辑漏洞项目上的实现框架，重在思路，未透露太多技术细节。 |
| 基于流量特征挖掘与AI推理的越权漏洞自动化识别 | 20250619，美团 SDL 技术专家气纯 | 通过海量日志分析，按照时间维度计算每个资源 id 的用户 Uid 访问情况，从而筛选出公私有数据，发现全量接口中私有数据仅占 2.5%，然后基于“多模型 COT 思维链 + 原子化任务拆分 + RAG 数据库技术应用 + Workflow 工程化“，让 AI 分析 HTTP 黑盒流量重放的报文，即高权限账户 Cookie + 低权限 Cookie 的响应差异，做到了越权漏洞 79% 的识别准确率 |
| 白盒+LLM：京东操作类越权自动化检测实践 | 20250730，京东安全应急响应中心 | 利用自研白盒引擎进行精准的代码资产梳理和数据流分析，构建用户身份（PIN）的参数传播图，锁定需要检测的接口。然后采用 Multi-Agent 协作来解决最复杂的部分：智能化地识别代码中多样化的鉴权逻辑（比如函数鉴权、注解鉴权），另外此项目重点针对的是操作类越权（公开信息的误报主要集中在查询类接口中，区分好数据操作类型能有效缓解误报），最终做到**准确率 90%+** |
| SAST结合大模型的逻辑漏洞识别探索 | 20250812，货拉拉技术-eureka.liu | 通过 SAST 生成含控制流 / 数据流的代码属性图（CPG），结合 RAG 构建项目专属向量知识库，再由 AI Agent 依托 ToT（思维树）、ReAct（推理 + 行动）框架，按 “建立认知（先分析项目架构和安全机制）→构想攻击路径→验证追踪→报告总结” 四阶段模拟人工审计流程，最终实现逻辑漏洞的高效识别。 |
| 研究了200天LLM，越权漏洞检测准确率才提升这点点？ | 20250818，字节跳动无恒实验室 | 致力于提升黑盒越权漏洞检测的准确率，解决因“公共信息接口”误判导致的误报瓶颈（ 超过 30% 的误报源于公共信息接口）。从精准问题定位出发，通过持续的技术迭代（Prompt→Few-shot→RAG→Reranker）来逐步解锁模型潜力，最终解决传统方法难以应对的模糊性判断问题。最终使得黑盒扫描越权检测中使用 LLM 识别 读公共信息接口的准确率达到 83.20%，写接口准确率 76.80%。 |
| AI代码审计的探索实践 | 20250828，陌陌安全 | 通过“SAST 静态分析工具（应该是 CodeQL）先行筛选污点链路 + AST 工具（Tree-sitter）提取精准代码链路代码” ，解决最小化传递必要信息给 LLM，克服大模型的长上下文导致的幻觉。再结合 “RAG知识增强 + 思维链 CoT”，进行深度语义审计，做到了平均 85% 左右的漏洞准确率。 |
| LLM白盒检测水平越权漏洞实践 | 20250919，平安科技实验室- 许纬地 | 基于 AST 工具 JavaParser 自研工具解析源码，将复杂审计任务拆解为串行的智能体协作流水线：“函数调用链查找 ---> 净化函数识别 ----> 漏洞业务危害分析”，平均漏洞准确率约60%。指出了 LLM 与 AST 交互的一个实践经验： 过多的对话与步骤提供的信息会让LLM任务结果不稳定与不准确，在审计任务中，一次性将相关函数代码给出来远比让 LLM一步步获取函数代码的效果更好 。 |
| 大模型驱动的越权检测：从智能协同到自主仲裁 | 20260104，携程安全应急响应中心 | 将白盒、IAST、黑盒工具的各自优势与 LLM 的语义理解能力相结合，构建了“1+1 >2 的多工具联合检测”方案，并引入 Gitlab MCP 工具 + 企业知识库 RAG，同时用小模型快速过滤掉大量低风险接口（如：已强制鉴权或处于内部服务网关后的接口、根据业务敏感度过滤公开 API、管理后台登录状态过滤），聚焦约15-20%的高风险接口，降低主模型负载，最终显著提升了越权漏洞检测的准确性（高达 89.5%）。 |
可能是在国内看到的最早的关于 AI 驱动代码审计的技术文章：使用llm来辅助静态扫描的人工审计。
作者提出了一种结合静态代码扫描和生成式人工智能（LLM）的自动代码审计系统，旨在利用 Semgrep 和 CodeQL 进行初步代码扫描，然后通过 LLM（如GPT-3.5）辅助确认审计结果，以提高代码审计的准确性和效率。
| 主题 | 内容描述 |
|---|---|
| 研究背景与目标 | 提出结合静态代码扫描和生成式人工智能（LLM）的自动代码审计系统，旨在提高代码审计的准确性和效率。 |
| 静态扫描工具选择 | + 工具：Semgrep 和 CodeQL ； + 原因：规则编写简单、功能强大，尤其在污点追踪方面表现突出。 |
| 输出格式选择 | - 格式：SARIF（静态分析结果交换格式）； - 优势：便于不同工具之间的结果交换和理解； |
| 系统核心实现 | - 框架：整合Semgrep、CodeQL 和 LLM； - 前端：基于 Choccy 项目魔改，实现友好UI界面； - 测试：通过 go 语言靶场测试，展示实际应用效果。 |
| Prompt 构建与优化 | - 关键要点： 1. 对于 Semgrep，将 sink 点周围的代码或整个文件加入prompt； 2. 对于 CodeQL，将 sink 和 source 代码加入 promp； 3. 添加扫描规则描述到 prompt 中； - 优化方法：补充企业内部常见的漏洞修复方法到 SAST 规则描述中，增强 LLM 识别能力。 |
| 输入代码的优化 | 引入更多辅助 LLM 分析的代码片段，如引入的包、配置等，以提高漏洞识别的准确率。 |
| SAST规则的负优化 | - 策略：放宽 SAST 对 Sink 的判断规则，将更多的潜在漏洞链路交给 LLM 去分析； - 目标：可以发现更多潜在漏洞，依靠 LLM 降低漏报率。 |
| 未来展望 | LLM在安全领域的应用前景广阔，如增量 API 提取、流程化工作等，通过 Agent 实现自动化流程可能是未来发展方向。 |
作者的核心思想如下：
广州朋克智能科技有限公司发布的商业化的 AI 驱动的代码审计产品：全球首个安全代码审计AI - CodeArgus。
| 类别 | 详情 |
|---|---|
| 产品名称 | CodeArgus |
| 开发公司 | 广州朋克智能科技有限公司 |
| 产品定位 | 全球首个安全代码审计 AI |
| 产品优势 - 对比传统人工代码审计 | 审计速度：几小时内完成，人工需几天到几周； 成本支出：显著降低审计成本，人工成本高昂； 能力水平：媲美资深安全研究员且质量稳定，人工依赖个体经验、水平参差不齐； 审计范围：支持多种编程语言，人工通常只能精通少数几种； |
| 产品优势 - 对比传统 SAST 工具 | 检测逻辑漏洞：能检测复杂逻辑漏洞，传统工具难以发现； 基于代码动态修补漏洞：发现漏洞并提供修补建议，传统工具仅报告漏洞； 低误报率和漏报率：使用先进技术降低误报漏报率，传统工具误报漏报多，增加工作负担； |
| 技术要点 | 通过软件分析师 Agent（负责代码静态分析，识别潜在复杂性和依赖关系）、软件工程师 Agent（分析代码作用和含义，提供安全审计上下文信息）、安全代码审计工程师 Agent（审查安全漏洞并制定修复方案）三个智能体协同工作。 |
| 使命与愿景 | 使命：应对全球网络安全人才短缺，解决企业面临的安全审计难题 愿景：利用 AI 技术填补网络安全人才缺口、降低网络安全成本，成为全球代码安全审计领域标杆，推动行业发展 |
| 官网 | www.codeargus.com |
CodeArgus 通过三个专门的 Agent 智能体协同工作，提供全面的代码审计解决方案：
软件分析师 Agent
- 软件分析师 Agent 负责代码的静态分析，它会解析软件的整体架构和程序流，通过详细检查代码结构和逻辑，识别出代码中的潜在复杂性和依赖关系。
软件工程师 Agent
- 在软件分析师 Agent 完成静态分析后，软件工程师 Agent 会进一步分析代码的具体作用和含义。它通过理解每一段代码的功能，为下一步的安全审计打下坚实基础。软件工程师 Agent 不仅确保代码逻辑清晰，还为安全漏洞的检测提供了必要的上下文信息。
安全代码审计工程师 Agent
- 安全代码审计工程师 Agent 全面审查代码中的安全漏洞。它会仔细检查每一个可能存在的风险点，确保没有任何细节被忽略。一旦发现安全漏洞，代码审计工程师会迅速制定详细的修复方案，并将其交给软件工程师 Agent 进行修复。
此产品的核心就是：通过多角色的 Agent 智能体协同，完整项目代码静态分析、代码理解、安全审计，使其能够支持多逻辑类漏洞的审计。
国外 Protect AI 组织开源的一款用于扫描 AI Python 代码漏洞的项目： vulnhuntr-first-0-day-vulnerabilities。
| 类别 | 详情 |
|---|---|
| 工具名称 | Vulnhuntr |
| 主要功能 | 借助大语言模型（如 Claude 3.5）查找并解释复杂、多步骤漏洞，针对 AI 生态系统中开源项目进行 0-day 漏洞检测 |
| 发现漏洞 | 多个热门项目中存在多种漏洞，如ComfyUI（XSS），FastChat（SSRF），Ragflow（RCE）等 |
| 工作原理 | 1. 代码分块处理：将代码分解为小的可管理块，自动搜索可能首先处理用户输入的文件，再处理整个文件并找出潜在漏洞，进而完成从用户输入到服务器输出的整个函数调用链分析。 2. LLM 驱动的调用链搜索：循环分析代码，不断请求所需的函数、类或代码片段，直至确定漏洞或排除可能性，最终给出详细分析报告。 3. 高级提示工程：精心设计提示，引导 LLM 高效工作，包括最佳实践提示工程、基于 XML 的提示、思维链提示和预填充标准输出格式的响应等。 |
| 局限性 | 目前仅支持 Python 项目（使用 Jedi 库做 Python AST 解析）；专注部分严重远程可利用漏洞，添加漏洞类型会增加运行时间；因 LLM 非确定性，多次运行结果可能不同，单次运行可能漏检。 |
| 面临挑战 | 在构建漏洞调用链时，检索增强生成（RAG）和微调模型的效果均不理想，RAG 在处理复杂代码结构时不准确，微调模型产生高误报率且无法检测跨文件漏洞。同时静态解析 Python 代码困难重重，现有解析工具存在不足。 |
| 未来展望 | 随着大语言模型上下文窗口变化，静态代码解析作用或改变，但手动解析代码在一段时间内仍有助于限制误报漏报；可在https://huntr.com 测试并获报酬。 |
Vulnhuntr 的强大之处在于它解决了一个代码审计的难点：通过 AI 去分析污点链路上所需要提取的上下文，根据需要提取相应的上下文代码，防止提取不必要的代码、分析不必要的逻辑分支导致“灾难级裂变式”的数据提取和跟踪。
Vulnhuntr 使用了一个聪明的技巧：它将代码分解成小的、可管理的块。它不是用多个完整文件压倒 LLM，而是智能地只请求代码的相关部分，执行外科手术式打击，而不是对整个代码库进行地毯式轰炸。它会自动在项目文件中搜索可能首先处理用户输入的文件。然后，它提取整个文件并响应所有潜在漏洞。使用这个潜在漏洞列表，它继续完成整个函数调用链，从用户输入到服务器输出，针对整个项目中的每个潜在漏洞，一次一个函数/类，直到它满意地拥有用于最终分析的整个调用链。这大大减少了误报（认为存在不存在的漏洞）和漏报（错过了确实存在的漏洞）。一旦 Vulnhuntr 开始分析文件，它就不会止步于表面。它会在循环中分析和重新分析，同时请求确认或否认漏洞所需的函数、类或其他相关代码片段。这种情况一直持续到 Vulnhuntr 看到足够的代码来绘制出从用户输入到服务器输出的完整路径。
关于 RAG 和微调，作者指出了它们的实践结果并不理想：
最后，作者也指出了未来大模型支持的上下文长度可能无限增大，但是也不影响精准化提取污点链路代码段所能带来的更好的漏洞检测结果。
由“中信建投金融科技+”提出的借助 LLM 探测越权漏洞：渗透测试：基于LLM增强的越权检测工具实践。
| 类别 | 详情 |
|---|---|
| 越权检测工具开发原因 | 1. 危害高：越权漏洞属高危漏洞，可致敏感数据泄露、资金被盗等严重后果，如 2019 年美国 First American 公司客户财务记录泄露事件 2. 普遍存在：在 OWASP TOP 10 2021 漏洞排行榜中位列第一；某公司 69 个系统渗透测试发现，权限类漏洞占比达 53%，居首位 3. 检测防治难：授权策略与业务相关，缺乏通用判定规则；越权请求无显著特征，难以通过请求特征检测；软件迭代时新接口权限检查易遗漏 4. 公司级检测可行：公司内系统数量有限且同类型系统权限配置相似，测试人员可基于权限模型配置工具，实现高准确率检测 |
| 越权检测工具设计与检测方案 | 1. 核心原理：重放接口，替换或置空认证信息，对比越权请求和原始请求响应结果或匹配自定义规则判定漏洞 2. 检测流程：人工完成系统权限建模、待测试接口识别、越权账户构造、测试用例构造；工具自动执行测试用例、越权检查、越权判定 3. 关键步骤 + 系统权限建模：用 {权限组，权限类型，受控对象} 三元组建模，权限组如角色等，权限类型分 “功能” 和 “数据”，受控对象指权限辖制资源 + 待测试接口识别：依据权限表和接口定义，按条件为接口打越权标签，分未授权、垂直、水平 - 读、水平 - 写四类 + 越权账户构造：垂直越权账户无 “功能” 类权限，水平越权账户无 “数据” 类权限但有全部功能权限 + 测试用例构造：基于 “凭证替换”，按越权标签生成用例，“水平 - 读” 需合法用例参照 + 越权检查：包括断言式检查（借助 LLM 对响应语义分类识别越权）和比较式检查（针对 “水平 - 读”，设计算法计算响应相似度） + 越权判定：采用分场景启发式规则，结果分越权、安全、未知三种 |
| 越权检测工具实践效果 | 1. 工具实现：基于 python3.8、HttpRunner2.0 开发 C 端工具，支持 Excel 格式输入输出 2. 输入：以含权限标签的 Excel 接口用例为输入，支持自定义响应体解析和成功标识 3. 输出：生成含检测结论、接口定义、账户信息、响应等内容的 Excel 报告，“未知” 接口提供命中检查项辅助复核 4. LLM 语义分类效果：对真实业务系统响应消息分类近乎无错，优于关键词字典方法 5. 越权检测成果：实测 5 个业务系统均存在越权风险，垂直越权最多，问题已反馈开发团队修复 |
| 未来计划 | 1. 广泛应用：应用于上线交付验收测试，将单个系统检测时间控制在 4 小时左右，识别更多安全隐患 2. 持续研究：纵向自动化测试用例构造提升效率；横向关注其他安全威胁，探索高效检测方法 |
文章的核心思想是：越权漏洞的检测主要是对比精心构造的不同请求包的响应数据，但实际的响应消息覆盖了中英文、包括多种句式和关键字的美好，可能说明了请求结果，又或者给出用户提示。这导致了采用关键词字典是难以覆盖完全的，而 LLM 出色的自然语言泛化能力能够做出近乎无错的分类。因此作者把主要 LLM 应用于负责对 HTTP 请求响应进行语义解析，从而准确判断接口是否存在越权漏洞。
腾讯 SRC 发布的文章：《大模型应用实践（一）：AI助力Code Review安全漏洞发现 - 博客 - 腾讯安全应急响应中心》。
| 类别 | 详情 |
|---|---|
| 技术背景 | 1. 代码漏洞是黑客窃取数据的主要途径，如 2023 年 MoveIt Transfer 的 sql 注入漏洞致大量数据泄露 2. Code Review（CR）能在开发阶段发现并修复漏洞，提升漏洞风险闭环效率，减少修复成本 3. 代码漏洞上线后影响大、发现难，CR 阶段修复可保障业务安全 |
| 传统代码漏洞检测方法弊端 | 主要依赖静态分析，需完整上下文信息，适用于项目级扫描。在 CR 场景中，扫描整个项目效率低，基于代码片段检测因无完整数据流难以奏效。 |
| 大模型应用于片段代码漏洞检测的可行性 | 1. 分析代码功能：大模型可利用其代码理解能力，识别各种代码写法下的代码功能，如辨别 SQL 语句拼接风险； 2. 分析数据流：借助大模型上下文理解能力，基于代码片段上下文分析 sink 点信息是否受外部可控，提高漏洞检测准确率； |
| 基于大模型的 CR 场景代码漏洞检测落地实践 | 1. CoT 提升推理能力：在提示词中给出漏洞检测推理过程示例，引导大模型按步骤分析，提升结果准确性； 2. 大模型与传统规则结合：利用大模型代码理解和生成能力，先按指定模式输出关键代码内容，再用规则规避误报； 3. 大模型输出结果结构化：让大模型按 json 格式输出，解决输出格式不规范导致的解析失败问题； |
| CR 场景漏洞检测效果 | 1. 整体成果：多轮优化后，漏洞检出准确率从 26% 提升至 95%，日均发现 300 + 个代码安全风险； 2. 典型案例：检出 Web 前端代码 AKSK 硬编码、订单系统 SQL 注入漏洞，避免数据泄露等严重后果； |
| 总结和展望 | 1. 长上下文失焦问题：可借鉴 MoE 模型，构建子模型分别处理不同漏洞问题，减少上下文数量，精准设计 prompt 和输出格式 2. 大模型幻觉问题：采用多模型投票方案解决； 3. 格式化输出的副作用：调用两次模型，先自由输出保障准确性，再总结格式化提高可用性； |
文章主要分析了腾讯安全团队对于 LLM 在 Code Review 上的实践经验，指出了大模型在代码审计上分析代码功能、跟踪数据流上的可行性，以及如何借助 COT、结构化输出等方式规范大模型的推理，最后总结了一些局限性和解决方法。
同样来自腾讯安全团队：AI猎手：我们用大模型挖到了0day漏洞！【大模型应用实践系列三】 - 博客 - 腾讯安全应急响应中心。
| 类别 | 详情 |
|---|---|
| 大模型技术方案调研 | 大模型应用于漏洞挖掘的方向及评估： + 直接基于大模型驱动：如 GPTScan 等，可识别未知漏洞，但局限于单一场景，评估结果可能受训练数据污染 + 大模型辅助模糊测试：像 ChatAFL 等，利用大模型作为输入生成和变异引擎提高模糊测试覆盖率，但大模型幻觉可能导致输入信息不准确 + 大模型辅助静态分析：如 LLift 框架，在分析潜在漏洞时准确率达 50% 且漏报率为零，但间接调用处理精度不足、变量重用易混淆 |
| AI 漏洞检测方案设计与实战 | 1. 检测方案设计： + 寻找漏洞入口：通过正则筛选项目代码中存在远程攻击入口的文件； + 初步漏洞标记：调用大模型评估代码入口文件，筛选高危文件，聚焦特定漏洞类型分析； + 代码深入分析：调用大模型多轮对话轮训，结合上下文补充信息深入分析代码； + 输出漏洞报告：当分析深度超阈值、大模型返回漏洞结果或分析到未知开源组件代码并完成漏洞特征推断时输出报告； 2. 0day 漏洞挖掘实战： + 实战过程：选取 GitHub 上收藏数排名前 500 的主流 Java 开源项目（尤其是 Web 应用项目），使用 AI 漏洞检测工具测试 + 实战成果：捕获 11 个高危 0day 漏洞，如某知名 AI 类应用产品的 XXE 漏洞，可致设备服务器权限被攻破；某知名工具类产品的 SSRF 漏洞，能让黑客窃取内网敏感文件 |
| 思考与展望 | 1. Token 限制和遍历深度问题：当前版本设计中，可通过大模型的java语法分析能力有效摘取上下文，但在 java项目体系中，也有不少漏洞具备多文件、多层级函数调用的特点，受 token 数约束，工具只能在有限深度阈值内检测漏洞，可能遗漏高价值漏洞； 2. 大模型幻觉问题：大模型幻觉会导致误判，将正常函数调用误认成漏洞点，增加漏洞验证成本，还可能使语法分析出错，影响漏洞报告准确性，造成误报；未来将优化这些问题，拓展功能并推动在更多安全场景落地； |
根据最新的文献调研，大模型应用于漏洞挖掘的方向大致可分为这几类：直接基于大模型驱动、大模型辅助模糊测试、大模型辅助静态分析等。其效果表现和局限性如下。
本文从工具设计理念和逻辑上，猜测就是腾讯安全团队借鉴了 Vulhuntr 的设计思路，二次开发实现了对 Java 源代码项目的支持。
来自“ 隐雾安全”微信公众号，A2Cai 的文章：《LLM 提高 SAST 的代审效率的思考方向》。
| 类别 | 详情 |
|---|---|
| 作者背景与写作目的 | 作者擅长黑盒漏洞挖掘，近期了解到用 SAST 进行代审，想探索借助 LLM 提高代审效率，基于 PHP 展开思考 |
| 借助工具人工代审步骤 （以 PHP 为例）及问题 | 1. 步骤： + 找到用户可控的 Source（框架类项目有固定模式，非框架类需分析路由和参数传递方式）； + 找到可能导致漏洞的 Sink（包括内置高风险函数和第三方扩展风险）； + 借助自动化工具找完整信息流后人工分析并尝试利用； 2. 问题：框架项目可能漏报；非框架项目人工分析费时费力且方案难沿用；污点函数需人工维护，分析代码量随其增多而增加；分析信息流时需关注数据变化； |
| 提高代审效率的要点 | + 确定是否有全局过滤，有的话对定位污点函数语句添加相应过滤； + 考虑更多用户可控的 Source； + 确保 Source 和 Sink 全面、语句高效； + 在数据流分析前排除被过滤和限制的污点函数； |
| 结合 LLM 提高代审效率的思路与问题 | 1. 思路：让 LLM 参与纯人工分析环节，提供数据让其分析推理并生成 Poc 验证；构造思维链模拟人工代审思维，如确定全局过滤、根据污点函数确定可利用输入数据类型、反向分析数据变化等； 2. LLM 做代码审计面临的问题： + LLM 受上下文限制无法读完所有代码，使用 RAG 的方式允许 LLM 进行代码的查询，但会丢失一些信息，例如：目录结构、文件名称； + 即便 LLM 可以查询所有的代码，但各部分之间联系薄弱，很难得出有效的信息； + 思维链存在问题，如数据量超上下文、同一函数不同调用增加工作量、业务复杂时工作量激增、难发现组合拳漏洞等； |
| 他人观点 | 1） 洺熙认为方向可行，RAG 检索片段应结合语义，COT 设计可更全面并引入知识库； 2）LLM 目前只能辅助审计，原因包括基于统计学预测、语义理解不够、审计结果依赖数据覆盖范围； 3）当下可关注多模态漏洞理解和自适应检测框架等应用辅助方向； |
| LLM 辅助漏洞挖掘demo | 输入 POST 请求信息，由 LLM 输出业务场景、参数分析、漏洞分析（认证 bypass、身份泄露、拒绝服务、SQL 注入等）及对应 PoC，总结指出存在潜在漏洞，建议后端服务安全升级优化，强调基于假设需结合实际调整 |
作者敏锐地总结了 LLM 在代码审计上的用武之地，也总结其当前存在的局限性，同时关键是给出了一个不错的思路：
知道创宇 404 实验室发布的文章：《本地化 AI 审计工具落地小试牛刀》。
| 类别 | 详情 |
|---|---|
| 文章背景 | 本文为知道创宇 404 实验室内部分享沙龙 “404 Open Day” 议题内容，属团队 AI 安全研究系列，用于交流学习。自 2022 年 ChatGPT 发布，人工智能代码审计成网络安全领域热点。 |
| 现存方案 | + ChatGPTScan - SAST：基于 ChatGPT 的开源代码审计平台，通过设计 prompt 使模型解析代码语义特征，经多轮对话引导 AI 完成漏洞模式匹配、风险评估，输出漏洞分级报告； + CodeArgus：采用多智能体协作，软件分析师解析软件架构和程序流，软件工程师分析代码作用，代码审计工程师分析风险点，发现漏洞后给出修复方案并修复，形成 “检测 - 修复” 闭环； + vulnhuntr：AI 提取项目 README 整合到 prompt，初筛识别潜在分析点，针对风险点生成检测命令二次分析，结合上下文关联分析，实现 “初步筛查 + 定向验证” 的代码漏洞排查； |
| 现存问题 | + 上下文窗口限制：代码审计中复杂调用链需跨模块追踪，大模型上下文窗口长度（通常 4k - 32k tokens）有限，处理深度调用关系时信息截断，导致语义偏离、逻辑断层，影响审计完整性 + 模型幻觉现象：大语言模型概率生成机制可能产生看似合理但错误的漏洞判定结论，增加误报筛查工作量，审计结果需严格人工验证 + 云端服务成本压力：高频调用、大规模代码库分析时，商业大模型 API 调用成本高，与安全研究员预算矛盾，处理百万行级代码项目费用指数级增长 + 地化部署困境：开源模型参数规模与推理性能矛盾，7B 以下小模型代码理解能力差，70B 以上大模型需专业级 GPU 集群支持，硬件资源门槛高，本地化部署难以达理想审计效果 |
| 本地方案 | 实验环境：qwen2.5 - coder:14b、llama_index 方案内容：将研究员模糊输入转换为计算机可理解命令输出，审计工具结果返回 AI 模型分析解读后输出结果 【解决问题及方法】 1） 让 AI 稳定输出计算机可识别命令：编写提示词时明确输出格式，给出模板，使 AI 按模板输出； 2） 让 AI 与外界交互：利用 AI 模型 tools（可调用的外部功能或服务），并给出相关代码实例。运行时根据用户输入判断是否调用 tools 执行计算机命令，不执行时为正常文本对话，执行时调用 tools，执行结果返回 AI 模型分析后反馈给用户； |
| 结论 | 当前多数 AI 模型代码审计存在问题，本文 “AI + 代码审计工具” 方案效果较理想。代码审计工具规则达一定数量可减轻安全研究员审计负担，使其投入研究，为网安行业带来新技巧和知识 |
本文主要作者通过借助 AI Agent 开源开发框架 llama_index，实现了用户与 AI 模型进行对话时，会根据用户的输入判断是否需要去调用 tools，用于执行计算机命令。当不要执行计算机命令时，就是正常的文本对话；而但需要执行命令时，则会去调用 tools 执行计算机命令，当命令执行结束后会将执行结果返回给 AI 模型，最后由 AI 模型分析执行命令的结果，最后返回给用户。
从视频演示可以看到作者是让 AI Agent 去自动调用 CodeQL 分析指定的源代码目录，并让 LLM 分析 codeql 的扫描结果。
同样来自知道创宇 404 实验室的文章：原创 Paper | 基于污点分析的 AI 自动化漏洞挖掘尝试。
| 类别 | 详情 |
|---|---|
| 文章背景 | 为知道创宇 404 实验室内部分享沙龙议题内容，属团队 AI 安全研究系列，受 Protect AI 的 vulnhuntr 项目启发撰写 |
| 研究思路 | 先逆向找 sink 到 source 的链路，再用 AI 做 source 到 sink 的正向污点分析判断链路连通性；适用于常规漏洞挖掘，尝试设计 V2 版本查找反序列化利用链 |
| 工具端 - V1 版 | 整体设计：处理类信息库（源代码用 AST 方式、字节码用 ASM 方式）和反向搜索链查找（自定义 Sink 和 Source 规则，用特定搜索算法） 反向找链原因：常规漏洞中 sink 比 source 少，可减少无效链路查找 附加提示信息：为每层调用添加提示信息，辅助 AI 处理特殊情况，如多线程类方法调用 |
| AI 端 - V1 版 | 整体设计：通过 API/RPC 获取 Java 端调用链信息，循环发送请求获取所需信息，由 AI 判断链路连通性 Prompt 设计：限定请求和响应模板，让 AI 判断调用栈污点传递连通性 分析方法：初始分析判断入口函数数据是否流入下层函数；污点传递分析关注有污点传递的调用；额外信息分析处理调用栈附加信息；可加入 sanitize 检测（当前因 AI 检测效果不佳未加入）。 |
| 漏洞演示 - V1 版 | 去年利用 XAI 的 grok 线上模型免费额度，对某 cms 旧版本进行测试，有演示视频 |
| 改版原因 - V2 版 | 受朋友启发，尝试挖掘反序列化利用链，JDK 中存在大量 method.invoke sink 点 |
| 试错过程 - V2 版 | 因链路分支多、内存易炸，尝试每两层做污点分析，提前中止无效链路 |
| 条件控制 - V2 版 | 检测被调用函数，处理多态情况；明确污点传递分析要点，如关注有污点传递的操作、判断所属类实际类型、处理特殊数据类型等 |
| 现实困境 - V2 版 | 控制条件多，模型测试效果不佳，出现忽略条件、不按格式查询响应等问题，条件拆分组合实现困难 |
| 结论 | 核心依赖 prompt 控制，不稳定；AI 适合赋能稳定架构，不能过度依赖；结合其他技术或可提升自动化漏洞挖掘效果 |
文章很经典，下面进行全文复制记录。
1、概述
本文是受 Protect AI 的 vulnhuntr 项目的启发，结合自己的经验做的另一种 AI 挖洞的尝试，如下图所示：
与 vulnhuntr 思路不同的是，我们**先逆向找到 sink 到 source 的链路，再利用 AI 做 Source 到 Sink 的正向污点分析来检测和判断整个链路的连通性**。当然这种方式只适用于调用链不是很深的常规漏洞挖掘，因为链路查找如果不做污点分析，对于反序列化利用链这种情况会延伸出很多无效链路，肯定是不现实的。后面我也设计了V2版本来适配做反序列化利用链的查找，但是用AI测试的效果并不好，不过只是一种尝试罢了。
为什么想用AI做污点分析？
最初的想法：用 AI 做污点传递连通性检测可能更有优势，它的知识量很大而且很智能，根据网页版交互使用体验和测试，它有时候确实能给你惊喜，所以做了下去。
2、调用链查找-工具端-V1版
大致分为两部分，一部分处理类信息库，一部分做反向搜索链的查找，如下图所示：
类信息库处理：
- 源代码：AST方式，优点是AI可能识别和处理效果好一点，缺点是信息的补全处理以及需要人工模拟栈调用
- 字节码：ASM，当然也可以反编译然后转AST方式，优点是不用补全信息以及栈模拟调用，缺点可能是AI识别和处理可能会差一点？也不一定，得看模型的处理能力
反向调用链查找：
- Sink 规则：可以自己收集，可以从一些开源的、非开源的工具提取
- Source 规则：可以是通用的框架、常规入口点，可以是根据实际审计环境自定义入口
- 搜索算法：由于没有做污点分析，Sink->Source 就是一直向上找 "who call me"，还有就是**多态、Object、Collection 等特殊情况的处理；**
- 提示信息：可以为每层调用添加提示 AI 的信息，例如多线程无显示调用，我在代码中做了关联，需要用提示信息提示 AI 做对应的处理；
为什么要反向找链？
附加提示信息：附加信息可以提示 AI 做对应的转换处理。
** 3、链路连通性检测-AI端-V1版**
由于目前 Java 对 AI 处理的适配性没有 Python、JS 好，所以做了 API/RPC 这种结构，AI 端需要的信息从远程 Java 端进行获取，如下图所示：
整体思路就是从 Java 端拿到调用链信息，发送携带调用链信息的 Request，响应的 Response 需要哪些信息，就在上一次 Request 的基础上添加这些信息，如此循环直到 AI 判断无法继续向下走或者拥有足够的信息能判断最终链路连通。
【Prompt 设计】
主要就是限定请求模板和相应模板做数据映射和控制，以及具体的分析方法。
【分析方法】
这里还可以加入 sanitize 检测，但是目前 AI 对 sanitize 的检测不太行，而且很多 bypass 方法 AI 可能还没有人工处理得好，因此这里没有加入。
【反序列化漏洞引起的 V2 版本】
当时是一个朋友问我，虽然最初的想法本就不是做这种反序列化的利用链的挖掘，但是还是做了下尝试，然后引出了改版以适配做这种反序列化利用链挖掘，如果能适配好有能力挖掘反序列化利用链的能力，那挖常规漏洞更是易如反掌了。
中间做了很多试错的测试，最后得出用每两层之间做污点分析的方法：从上一层->sink，上上层->上一层...，通过使用这种思路，如果 sink->上一层的通路都无法进行了，那就没必要继续了。这种方式提前加入污点分析，就能更早中止链路，防止后续无效链路的延伸。
为了防止无效链路出现，需要加入更多的条件控制，对于每两层调用，首先要做的就是检测被调用函数，如下图所示：
这里其实是对多态的处理，需要 AI 根据上下文推测实际的类型，如果没有绑定其他类型并且该处调用是属性对象、参数对象或经过污染的对象调用，那么这个位置才能被认为可以用被调用函数替代。
污点分析的条件控制：
图中红色标记处也是处理多态的情况，只是这是在两层调用之间出现的中间调用。
由于控制条件太多，抑或是我的 prompt 无法准确描述想要的东西，测试过一些本地模型和线上模型，实际效果都不太好：
后面也想过做条件拆分，在代码中做结果整合，但是很棘手，因为漏洞本身就是需要上下文和条件控制的，仅根据我目前的认知，漏洞挖掘这个场景做条件拆分再组合我实在是很难办到。
【文章结论】
可以看到上面所做的工作，核心的东西都是利用 prompt 描述做控制，强依赖 AI，中间过程具有极其的不稳定性。其实在做 V 1和 V2 版本的过程中，我就意识到自己在做一个对标 codeql 的东西，但是我知道凭我是肯定没办法实现 codeql 那种效果的，想用几千个文字描述 codeql 做的东西，确实有些异想天开了，不过较下劲尝试下，毕竟它有时候确实能给你惊喜。经过这一系列折腾，给我的感觉是对于这类条件控制很多或者需要精细处理的场景，AI 只有赋能在已经具有稳定性的架构中，核心的东西不能过于强依赖 AI，才可能最大的发挥 AI 的作用以及获得较好的效果。
以上只是本人结合 AI 做漏洞挖掘粗浅和拙劣认知，AI 目前还有很多技术，结合这些技术或许能在自动化漏洞挖掘方面达到期望的效果。
来自腾讯云鼎实验室的文章：从人工困局到智能破局 - 大模型在代码安全审计的探索与实践。
| 类别 | 详情 |
|---|---|
| 传统代码安全审计的困局 | 1. 问题：静态应用安全测试（SAST）工具在代码安全审计时，因不支持云产品使用的开源组件和框架，导致数据流覆盖不全，引发漏报 2. 传统解决方法：组织安全工程师人工分析开源框架，编写检测规则集成到工具中 3. 传统方法的挑战：人工分析效率低，全量分析一个框架至少需 1 小时；经验依赖性强，不同工程师结论可能不同，面对多语言、多技术栈框架人力投入大；审计质量不稳定，易出现漏报和误报 |
| 直接应用大模型的挑战 | 1. 漏洞存在≠实际可利用：存在漏洞风险的代码，需有攻击者可远程控制的输入点等条件才会被利用 2. 上下文超过模型长度限制：真实项目中代码风险点的上下文和调用链路长，超出大模型 8K/32K 的长度限制 3. 知识沉淀无法转化为检测效能：安全团队积累的已知代码风险点，大模型仍当作未知风险检测，外接知识库也难以匹配业务代码和已知风险点 |
| 大模型赋能的破局之道 | 设计大模型驱动的污点检测流程，通过三个 Agent 协同挖掘开源框架中的污点： 1. Discover Agent：初筛引擎用通用大模型全量扫描框架源码，识别潜在 Source 和 Sink 函数；验证引擎用增强模型验证候选函数； 2. Judge Agent：利用专家经验对筛选出的备选污点函数进行验证，排除不符合条件的函数 3. Validation Agent：对几千个使用该框架的仓库进行代码安全审计，验证挖掘出的污点是否真实有效 |
| 成果 | 1. 内部审计提升：内部代码安全审计工具检测结果数量提升 10%+，提高了未知风险检出率 2. 漏洞挖掘：挖掘出 4 个 0day 漏洞，如 Apache Traffic Control 项目的 CVE-2024-45387 漏洞（CVSS 评分 9.9），该漏洞未被 CodeQL 检测出，凸显大模型扩展 Sink 点检测能力的作用 |
| 未来展望 | 积极探索利用大模型提高代码安全审计准确率，持续强化腾讯云的代码安全审计能力 |
感觉本文更像是云鼎实验室秀数据之用……没太多干货。核心就是设计了 Multi-Agent 协同，分别用于发现基于文件粒度识别的 Source/Sink --> 函数代码识别提取 --> 进行污点链路分析。但是前两步真的有必要用 AI 去做？SAST 或本地脚本不能完成么？
来自字节的技术沙龙：《白盒 + LLM漏洞挖掘的探索和实践》。
| 核心模块 | 核心要点 |
|---|---|
| 逻辑漏洞现状 | 1. 漏洞占比：逻辑漏洞（越权、未授权、权限绕过等）占比 > 60%，传统漏洞（SQL 注入等）<20%，成为企业人力投入最多的漏洞类型； 2. 常见类型：越权、未授权、权限绕过、业务流程逻辑漏洞等； 3. 现有检测方式：主要依赖人工挖掘 + 工具规则实现。 |
| 逻辑漏洞白盒自动化检测的困境 | 1. 传统检测方案条件：需满足 “敏感操作接口（增删查改敏感数据等）+ 存在越权逻辑（可控资源标识符操作非本人资源）+ 无鉴权逻辑（无垂直 / 水平鉴权）”； 2. 传统方案实现：规则匹配路径 / 人工打标识别接口、规则 + 数据流分析识别越权逻辑、二方组件 + 鉴权函数规则识别鉴权； 3. 核心困境：① 无法真正理解代码语义，规则有限，准召率不足；② 逻辑场景代码写法多样，规则维护费时、难度大，无法泛化； 4. 典型问题案例： ① 200+“发送验证码” 类公开接口未被规则识别；② 依赖编码规范或关键字 / AST 规则，鉴权逻辑易漏判；③ 漏洞 sink 场景（orm、mongo、rpc、kafka 等）过多，难以全覆盖。 |
| 大模型挖洞的可行性与实践 | 1. 学术观点（2024 S&P 论文）：大模型直接漏洞检测存在不稳定、准确率低、结论不可信等问题； 2. 大模型劣势：① 上下文 token 有限，难以处理 10w + 行代码的静态分析；② 任务拆解与规划能力差；③ 存在幻觉问题（倾向报告漏洞、前后矛盾）； 3. 解决方案：① 结合 SAST 等工具弥补长代码处理短板；② 通过良好 prompt、few-shot 优化幻觉问题；③ 人为定义 workflow，让大模型聚焦适合的原子任务； 4. 学术界探索： ① 智能合约逻辑漏洞检测（如 GPTScan，结合大模型语义理解与静态分析确认漏洞）； ② LLM 辅助静态分析（如 IRIS 生成规则、过滤误报；OOPSLA 2024 方案通过约束引导判断 UBI 漏洞；ASE 2025 方案优化 SAST 间接调用分析）。 |
没太多干货，更多的是给出他们实践的一些现象和结论，没有技术实现细节……
一些有价值的观点：
来源于美团技术分享沙龙：《基于流量特征挖掘与AI推理的越权漏洞自动化识别》。
🎯分享基于流量分析与AI智能运营的越权漏洞治理实践。重点解析了“数据私有分析”和“AI打工日常”。通过海量业务日志中私有接口的识别，构建高价值接口检测通道；基于RAG技术动态知识融合进行多模型协同推理，通过权限关系建模、业务逻辑深度解析及风险动态评估，将安全运营从"人工筛漏洞"升级为"智能控全局"，联动打造AI驱动的全流程自动化越权漏洞识别体系。
⛳总结下值得学习的点：
- 通过海量日志分析，按照时间维度计算每个资源 id 的用户 Uid 访问情况，从而筛选出公私有数据，发现全量接口中私有数据仅占 2.5%，从而筛选掉大量无需检查的公有数据接口；
- 基于“多模型 COT 思维链 + 原子化任务拆分 + RAG 数据库技术应用 + Workflow 工程化“，让 AI 分析 HTTP 黑盒流量重放的报文，即高权限账户 Cookie + 低权限 Cookie 的响应差异，做到了越权漏洞 79% 的识别准确率；
| AI推理发现越权问题的挑战 | 解决方案 |
|---|---|
| 不可预知性：生成具有不确定性、可能包含预测外的推理逻辑 | 使用“自我一致性”模式（例如多模型的思维链形式），“原子化”AI任务以提升整体鲁棒性；同时采用三分法而非二分法，允许大模型回答”不太确定“，增强可解释性 |
| 黑样本倾向性：对于黑样本检测能力较好，但对于白样本（误报）识别能力差，容易误报 | 定制合适的工作流，AI 只完成特定原子任务，复杂问题由安全工程师解决 |
| 专业知识召回要求高：在研判候选越权漏洞时，对安全及业务知识召回要求高，关键信息缺失会导致推理失效 | 使用基于 Modular 的 RAG 技术，在必要时支持条件、分支或循环查询；不同知识模块采用差异化的检索与排序策略 |
| 处理效率和成本：AI处理效率优于人工，但难以覆盖百万级别接口，会消耗大量Token | 识别关键性私有接口，聚焦于核心资产进行分析 |
:::color2 🎯针对 AI 判断漏洞 ”疑神疑鬼“ 的问题：采用工程技术替换AI！AI 爆火的时候，思考 AI 能做什么？冷静下来以后，思考什么是不需要 AI 就能做的？
:::
来自货拉拉技术的公众号分享：《SAST结合大模型的逻辑漏洞识别探索》。
| 维度 | 核心要点 | 说明 |
|---|---|---|
| 背景与问题 | 传统SAST的困境 | 擅长检测SQL注入等模式化漏洞，但无法理解业务逻辑，因此几乎无法发现支付绕过、越权访问等与业务流程深度绑定的逻辑漏洞。 |
| 人工审计的优势与瓶颈 | 安全专家能理解上下文和业务逻辑，但过程耗时耗力、效率低下，难以规模化。 | |
| 核心思路 | AI代理模拟专家审计 | 不直接将整个项目“投喂”给大模型，而是构建一个由AI驱动的流水线，将人类审计流程拆解为可自动化执行的阶段。 |
技术框架与阶段 |
1）建立认知 | 目标：让AI理解项目代码和架构。 技术：RAG。先用SAST工具生成代码属性图，提取API、数据流等信息，构建成可被检索的向量知识库，为分析提供准确上下文。 |
| 2）构想攻击路径 | 目标：像专家一样进行威胁建模，提出可能的攻击假设。 技术：ToT。引导LLM针对识别出的核心功能（如订单创建），生成“攻击假设树”（如价格篡改、越权等分支），并进行初步评估和剪枝。 | |
| 3）验证追踪 | 目标：严谨地验证攻击假设，形成证据链。 技术：ReAct。AI代理循环执行 “推理-行动-观察”：制定计划 -> 调用工具（如数据流分析）-> 审查结果 -> 得出结论，有效减少大模型的“幻觉”。 | |
| 4）报告总结与修复 | 目标：生成包含严重性评估、证据链和修复代码建议的完整报告，形成闭环。 | |
| 效果评估 | 测试结果 | 在包含10个已知逻辑漏洞的靶场中测试：召回率：60%（发现6个），准确率：83%（5个为真），效率：约25分钟完成，效率估算为人工的10倍。 |
| 局限性 | 面临的挑战 | 1）知识库质量：底层SAST工具分析的准确性是基石。 2）工具集设计：需要精心设计通用且强大的工具来支持ReAct框架。 3）LLM的“幻觉”：复杂推理中仍可能误解或循环。 4）成本与效率平衡：深度推理调用成本高，需优化以适应CI/CD流程。 |
⛳总结下值得学习的点：
- 程序执行初期通过 Agent + SAST 构建的 CPG 结合，先完成对项目技术架构、安全机制、应用业务概述的分析；
- 采用 ToT(Tree-of-Thoughts) 框架驱动：ToT是一种让LLM模仿人类进行复杂问题解决的思维模式。当人类专家面对一个需要战略规划或探索的任务时，通常不会沿着一条路走到黑，而是会同时思考多种可能性，评估优劣，然后选择最有希望的路径深入探索。ToT框架就是将这种“思维树”的探索过程赋予了 LLM，使其能够进行有效的头脑风暴和威胁建模。
整体的数据流程图如下所示：
来源于京东安全应急响应中心的公众号文章：《白盒+LLM：京东操作类越权自动化检测实践》。
| 维度 | 核心要点 | 说明与解读 |
|---|---|---|
| 背景与目标 | 解决操作类越权漏洞的自动化检测 | 目标是检测对数据增、删、改操作的越权风险。传统黑白盒工具对此类逻辑漏洞误报率高，且涉及业务改造的加固方案成本高。 |
| 核心方案 | “白盒构建基础，LLM做上层判断”的混合架构 | + 白盒引擎：负责代码解析、构建数据流图，精准追踪用户身份标识（PIN）的传播路径，为LLM提供结构化代码上下文。 + LLM (Multi-Agent)：负责理解代码语义，基于白盒提供的“PIN流图”等信息，判断是否存在有效的鉴权逻辑。 |
三大关键问题与解决 |
1）如何判断API是否需要鉴权？ | 方案：通过白盒引擎识别数据操作方法（如解析 Mybatis 的 insert/update/delete 标签），精准圈定需要检测的操作类接口范围，过滤掉大量公开的查询接口。 |
| 2）如何判断API是否存在鉴权？ | + 白盒：构建 “PIN数据流图” ，追踪用户身份参数在代码中的传播路径。 + LLM：基于流图、代码片段等上下文，识别多种鉴权形式（函数鉴权、注解鉴权、SQL鉴权等）。 |
|
| 3）如何判断鉴权实现是否符合预期？ | 方案：LLM (Few-shot prompting) 是关键。将安全专家总结的十余种鉴权绕过场景规则（如多参数校验不全、返回值判断不严）输入模型，使其能发现“有鉴权但无效”的漏洞。 | |
| 技术亮点 | 构建“PIN数据流图” | 与传统污点分析追踪“用户输入”不同，本方案创新地改为单独追踪“用户身份(PIN)” 的传播路径。这使得分析目标更聚焦，有效减少了需要LLM处理的代码量，并确保鉴权逻辑点必然存在于该流图中。 |
| LLM的应用方式 (Multi-Agent) | 并未训练专用模型，而是使用通用大模型，并通过设计多个专用Agent来分解复杂任务（如一个识别鉴权函数，另一个判断鉴权是否有效），从而减少“幻觉”并提升准确性。 | |
| 落地效果 | 在某业务线的准确率 | + AI识别无风险场景（存在有效鉴权）：准确率 90%+ + AI识别有风险场景（存在漏洞）：准确率 70%+ 能力已应用于SDL安全评估流程，实现自动检出、人工反馈的闭环优化。 |
| 未来规划 | 黑白盒+LLM联动 | 目标是实现 “白盒检测、黑盒验证” 的精准联动，以更低的成本确认高风险漏洞，推动修复。 |
⛳总结下值得学习的点：
- 重点针对的是**操作类越权：_公开信息的误报主要集中在查询类接口中，__区分好数据操作类型能有效缓解误报**_，故京东此项目会先区分查询和操作（增/删/改）类接口，重点关注操作类越权；
- 没有基于集团代码训练自己的小模型，而是选用通用大模型。为什么不微调一个“小”模型而采用“大模型”？首先大模型大迭代速度快，我们微调的“小”模型在模型快速发展的今天，相比较优势不明显，其次现在大模型超长的上下文和代码理解能力，已经可以满足当前需求；
- 采用 Multi-Agent 协同完成复杂任务，为了减少因上下文过长导致的“幻觉”问题，拆分为多个 Agent 用来识别不同场景下的鉴权逻辑，比如函数健全逻辑识别、注解鉴权逻辑识别、SQL 鉴权逻辑识别等。
多模型整体协作流程如下所示：
来源于字节跳动安全中心公众号的文章（出自无恒实验室）：《研究了200天LLM，越权漏洞检测准确率才提升这点点？》
| 维度 | 核心内容与亮点 |
|---|---|
| 核心目标 | 提升黑盒越权漏洞检测的准确率，解决因“公共信息接口”误判导致的误报瓶颈。 |
| 问题诊断 | 传统规则优化将准确率从不足20%提升至35%后陷入瓶颈，分析发现 超过30%的误报源于公共信息接口。 |
| 核心思路 | 利用LLM的语义理解能力，判断一个接口返回的是用户个性化数据还是所有用户均可访问的公共信息。 |
| 技术方案演进 | 1. 基础Prompt工程：定义任务与角色，但效果有限。 2. Few-shot Learning：在Prompt中提供正负样例，准确率提升至约70%，但遭遇瓶颈。 3. 检索增强生成 (RAG)：动态检索相似接口样例，大幅提升效果。 4. Reranker & 两阶段检索：在RAG基础上引入重排序，精准筛选最相关样例，达到最佳效果。 |
| 关键效果 | 读接口的公共信息识别准确率达到 83.20%，召回率 82.57%，推动整体越权检测准确率提升至55%。 |
| 方案拓展 | 对于更复杂的写接口，引入SQL语句作为关键上下文提供给LLM分析，以判断操作是否影响公共数据。 |
| 实践启示 | 展示了将LLM落地于专业场景的典型路径：从精准问题定位出发，通过持续的技术迭代（Prompt→Few-shot→RAG→Reranker）来逐步解锁模型潜力，最终解决传统方法难以应对的模糊性判断问题。 |
⛳总结下值得学习的点：
- 指出了越权漏洞的误报核心：公共信息接口，并通过实例说明了识别公共信息读、写接口的难点；
- 通过持续的技术迭代（Prompt→Few-shot→RAG→Reranker）来逐步解锁模型潜力，最终解决传统方法难以应对的模糊性判断问题。
来源于陌陌安全的公众号文章：《AI代码审计的探索实践》。
| 维度 | 核心内容 |
|---|---|
| 核心目标 | 解决将AI（特别是大模型）应用于企业级代码审计时面临的关键难题，实现高效、准确的自动化安全检测。 |
| 面临的技术难点 | 1. 模型隐私：企业代码敏感，不能使用外部商用模型。 2. 长上下文限制：项目代码量大，超出模型处理能力，且导致注意力分散。 3. 跨文件/项目审计：漏洞链涉及多个文件甚至仓库，需要整体分析框架。 4. 模型能力不足：开源模型在漏洞检测精度上存在局限。 |
| 核心解决方案（技术选型） | 1. 自部署模型：在本地部署开源模型，保障代码隐私安全。 2. 静态分析 + LLM 混合架构：用静态分析工具（如代码分析引擎、AST解析）先行扫描，精准提取漏洞关键代码链路，解决长上下文问题。 3. 引入RAG技术：构建由安全专家经验组成的外部知识库，动态增强模型对特定漏洞的检测能力，无需重新训练模型。 |
| 实现落地的关键组件 | 1. 代码分析引擎：执行初步静态扫描，生成漏洞链路报告。 2. AST解析器：从链路中精准定位并提取关键代码上下文。 3. Agent分析师：处理超长调用链，进行分段深度分析。 4. 代码审计师（LLM）：结合思维链（CoT）方案，利用提供的上下文和RAG知识，进行最终推理判断并生成报告。 |
| 实践结果 | 在内部项目中对三类漏洞的检测准确率为：SSRF（96.17%）、SQL注入（77.46%）、RCE（85.71%），验证了架构的有效性。 |
| 现存挑战与方向 | 静态规则在提取逻辑漏洞完整链路上存在不足，规则覆盖性依赖知识库。未来探索方向是基于代码流图的检测，以覆盖更复杂的漏洞类型。 |
⛳总结下值得学习的点：
- 通过“SAST 静态分析工具（应该是 CodeQL）先行筛选污点链路 + AST 工具（Tree-sitter）提取精准代码链路代码” ，解决最小化传递必要信息给 LLM，克服大模型的长上下文导致的幻觉；
- 再结合 “RAG知识增强 + 思维链 CoT”，进行深度语义审计，做到了平均 85% 左右的漏洞准确率（这个准确率还是比较高的）。
程序的整体流程图如下所示：
来自平安集团安全应急响应中心公众号分享的安全沙龙议题：《LLM白盒检测水平越权漏洞实践》。
| 维度 | 核心内容 |
|---|---|
| 核心目标 | 利用 LLM 技术，解决企业中缺乏有效工具检测水平越权漏洞（Row-Level Security）的痛点，实现自动化白盒审计。 |
| 对漏洞的理解 | 将水平越权视为行级数据安全问题。审计关键在于识别代码中可信的用户身份ID（如登录态）是否对不可信的数据操作（如订单号参数）构成了有效的权限校验。 |
| 核心技术路径 | 1. 构建 AST 工具：基于 JavaParser 自研工具解析源码，输出结构化数据（如函数调用图、SQL语句、类信息），作为LLM理解的上下文。 2. 设计多 Agent 工作流：将复杂审计任务拆解为串行的智能体协作流水线： sink finder-> function review -> business review - Sink Finder：定位数据操作点（如SQL、RPC调用）和函数调用链； - Function Review：审计从入口到污点的函数流程，判断权限校验有效性； - Business Review：业务审计角色，结合业务场景判断潜在漏洞的实际危害； |
| 提示词与工程要点 | 1. 结构化指令链：将审计步骤分解为明确的“有限状态机”，严格约束 LLM 推理路径。 2. 上下文管理：一次性提供相关完整代码块，效果优于让 LLM 多次调用工具获取。 3. 输出分离：将“推理过程”与“格式化的报告输出”分离，避免干扰模型判断。 |
| 实践效果 | 1. 模型对比：在函数过程审计上，DeepSeek-R1 模型准确率（91%）显著高于其他模型。 2. 真实项目：在多个项目中，业务审计环节的平均漏洞准确率约60%，但对历史已知漏洞的 检出率达到100%。生成的报告（含漏洞链、可信参数、业务影响字段）实用性强。 |
| 缺陷与展望 | 1. 当前缺陷：“提示词工程”方式存在机制天花板，LLM仍需处理大量代码。理想模式应是LLM与强数据流分析的SAST工具深度结合。 2. 未来方向：需构建业务知识库并动态引入，以解决业务场景判断的难点；对于了解自身业务的团队，可让人工专注审核“函数审计结果”。 |
⛳总结下值得学习的点：
- 基于 AST 工具 JavaParser 自研工具解析源码，将复杂审计任务拆解为串行的智能体协作流水线： sink finder -> function review -> business review ，即“函数调用链查找 ---> 净化函数识别 ----> 漏洞业务危害分析”；
- 指出了 LLM 与 AST 交互的一个实践经验： 过多的对话与步骤提供的信息会让LLM任务结果不稳定与不准确，在审计任务中，一次性将相关函数代码给出来远比让 LLM一步步获取函数代码的效果更好 。
总的来说，平安科技的这个分享议题里所呈现的系统架构相比其它大厂要简单得多。采用纯粹的 AST 而非 SAST、缺乏企业级专属 RAG 知识库，大概率此项目也仅仅是平安实验室里处于试验开发阶段的工具。
来源于携程安全应急响应中心的公众号文章：《大模型驱动的越权检测：从智能协同到自主仲裁》。
| 维度 | 核心内容 |
|---|---|
| 核心问题 | 传统越权检测（SAST/IAST/黑盒）存在语义理解、覆盖率、精确判断等瓶颈，而单独使用LLM则存在 幻觉、高误报、上下文依赖强 等问题。 |
| 破局思路 | 让 LLM 充当“智能仲裁者”，融合多源数据，构建 “上帝视角” 。即融合白盒（代码意图）、IAST（运行时行为）、黑盒（重放测试）的数据，为LLM提供充分、互补的判断依据。 |
| 核心方案 | “联合检测”架构与两阶段LLM工作流： 1. 阶段一（前置过滤）：用小模型快速过滤掉大量低风险接口（如已鉴权网关、公开API），聚焦约15-20%的高疑接口，降低主模型负载。 2. 阶段二（深度研判）：根据白盒与IAST结果是否一致，分场景处理： - 一致（高置信）：快速验证，直接输出判断。 - 冲突（复杂）：触发多轮验证，LLM结合MCP工具主动查询代码、配置等补充信息，进行最终裁决。 |
| 关键技术 | 1. MCP工具增强：让LLM从“被动判官”变为“主动侦探”，例如通过<font style="color:rgb(15, 17, 21);background-color:rgb(235, 238, 242);">gitlab mcp</font>批量查询代码片段，解决上下文缺失问题，大幅降低耗时与Token消耗。 2. 企业知识库：注入内部权限模型、历史漏洞等知识，使通用模型适配企业特定业务，提升判断准确性。 |
| 实践效果 | 1. 检测能力：在测试集上达到准确率 89.5%。 2. 运营成效：相比纯人工测试，漏洞检出数量增长4倍以上，有效收敛了外部攻击面。 |
⛳总结下值得学习的点：
- 将白盒、IAST、黑盒工具的各自优势与 LLM 的语义理解能力相结合，构建了“1+1 >2 的多工具联合检测”方案，并引入 Gitlab MCP 工具让 LLM 能主动获取代码信息，从而在显著提升了越权漏洞检测的准确性、覆盖面和自动化程度；
- 白盒、IAST、黑盒作为联合检测的数据源，白盒需要提供关键切面代码、鉴权检测函数片段、已经鉴权的参数集；IAST 则需要提供原始采集的请求信息、调用黑盒重放后的请求信息，运行时的 SQL 信息；
- 用小模型快速过滤掉大量低风险接口（如：已强制鉴权或处于内部服务网关后的接口、根据业务敏感度过滤公开 API、管理后台登录状态过滤），聚焦约15-20%的高疑接口，降低主模型负载。
【需要注意】作者提到：鉴于内外部接口鉴权机制存在本质差异（后台重 RBAC 角色功能权限，外部重数据归属），基于风险优先级考量，他们目前聚焦外部接口的深度越权治理，对内部接口则暂行SSO登录态基础检测，未来将适配专用策略精细化覆盖。
提出的“联合检测”架构图如下：
LLM 工作流程如下：
