核心内容摘要
解锁艺术密码，点亮人文之光——西西人文艺术课高清教学视频，开启你的深度体验之旅
前言在当今快速发展的软件开发环境中安全漏洞管理正在经历一场深刻的变革。
随着 DevOps 理念的广泛普及安全左移Shift Left Security已成为行业共识企业纷纷将安全检测前置到开发流程的早期阶段构建真正的 DevSecOps 体系去哪儿网也基于微软提出的软件开发生命周期SDLC将安全左移嵌入 DevOps 流程中。
在实际工程实践中SAST 作为安全检测的核心能力承担着漏洞发现的兜底责任而 IAST 和 DAST 更多作为补充手段。
这种架构设计使得 SAST 的运营质量直接决定了整个安全漏洞管理体系的有效性。
安全开发生命周期SDLC中的白盒扫描环节一直面临着严峻挑战业内比较优秀的静态应用安全测试SAST工具的准确率基本也维持在
%左右大量人力消耗在漏洞真实性确认上。
大部分互联网公司安全团队在 SDLC 上的人力投入可达 40% 甚至更多。
SDLC 白盒漏洞管理的行业通用流程在大多数企业的 SDLC 流程中白盒漏洞管理通常包含以下几个步骤代码提交触发扫描开发提交代码后由 CI 系统自动触发 SAST 工具如 Fortify、Checkmarx、SonarQube、Coverity 等进行静态扫描。
生成初始漏洞报告SAST 工具会输出检测结果通常包括漏洞类型、源文件路径、调用链、风险等级等格式可能是 XML、JSON、PDF、Word、SARIF 等。
人工审核与确认安全工程师需要对漏洞逐一审查验证该漏洞是否误报主要确认输入点外部是否可控、是否已做白名单过滤或类型检查等漏洞归类与派单审核通过后根据系统、模块、责任人信息将漏洞录入工单系统派发至对应的开发或业务团队。
漏洞修复与复审研发根据漏洞详情和修复建议对漏洞进行修复安全团队复测验证修复效果最终关闭漏洞记录。
数据沉淀与运营分析安全团队对漏洞数量、类型分布、修复时长MTTR、责任归属等指标进行归档与复盘优化规则和策略。
流程示意图如下然而该流程存在以下几类通用难点SAST 误报率高 → 人工审核压力大SAST 审核效率低 → 单个漏洞人工审核至少要
分钟审核缺乏标准化 → 不同工程师审核结论可能不一致
Multi-Agent 智能漏洞审核系统设计理念针对传统 SAST 面临的挑战我们引入了Multi-Agent多智能体架构旨在构建一个AI自动化、专业化、可扩展的白盒漏洞智能审核系统。
该系统的核心理念在于将复杂的漏洞审核任务分解为多个协作的、具备特定能力的 AI 智能体通过任务的智能调度、专业化分析与分层复核实现漏洞的精准识别与自动化处理。
示意图如下核心思路主要体现在以下几个方面
专业化分工不同类型的安全漏洞如 SQL 注入、SSRF、命令注入等往往涉及不同的攻击原理、检测方法和上下文分析。
传统的单一审核流程难以兼顾所有细节。
多智能体架构通过构建专精于特定漏洞类型的智能体确保每个漏洞都能得到最专业的分析从而大幅提升审核的准确率和深度。
自动化协同系统通过智能调度代理自动识别漏洞类型并将其分发给相应的专业审核代理实现审核流程的自动化流转。
这不仅减少了人工干预也极大地提升了处理效率。
可扩展性与灵活性随着新漏洞类型和新攻击手法的不断出现系统需要具备快速适应和扩展的能力。
多智能体架构的核心优势针对不同漏洞类型可以独立调优且不会影响其他 Agent 的效果。
质量保障与复核机制为确保审核结果的可靠性系统设计了汇总分析 Agent的角色。
该代理负责对初审代理的报告进行复核提炼最终结论并生成标准化的结构化数据为后续的自动化工单推送提供准确依据有效避免了因单一 AI 判断而可能出现的偏差。
系统架构与核心 Agent 角色我们构建的智能审核系统以 n8n 为编排平台以 DeepSeek-V3 大语言模型为基础围绕以下组件展开
输入与数据获取层支持 webhook 接入、工作流触发等多种入口根据漏洞哈希调用内部 SAST API 获取漏洞详情SAST 平台本身提供丰富的漏洞信息可用于漏洞审核分析项目基础信息漏洞基本信息漏洞 SARIF 标准数据
任务调度 Agent根据 rule_name 映射漏洞类型如sql-injection→sql_injection_agent将任务分发给对应专业审核 Agent。
任务分发规则
专业审核 Agent每个 Agent 审核一种漏洞类型能调用SAST MCP和Gitlab MCP获取调用链、源码片段、字段类型等上下文信息输出 Markdown 审核报告包含分析过程、判断逻辑、风险描述与修复建议。
Agent Prompt 编写建议Agent 的 Prompt 是这个系统里面最重要的部分核心思路是将复杂专业任务分解为可控制、可验证、可重复的标准化流程。
我在编写了上万字的 Prompt 后
总结出的主要心得如下Prompt 并不是越长越好2024 年我们第一次尝试大模型漏洞审核的时候我们的第一个 Prompt 长达 5000字符效果并不是很好。
根据经验来看当 Prompt 的字符数达到 2000以上就容易出现幻觉或推理错误的问题所以编写 Prompt 要尽可能的简练。
Prompt 需要持续优化没有哪个有效的 prompt 是一次性写完的大部分情况下我们需要监控 AI 的运行过程理解 AI 的执行过程发现 AI 思路上的错误通过 prompt 指令进行优化。
大模型需要足够的信息大模型主要是代替人的思考前提是它能获取到足够的信息进行思考和分析善用 MCP/FunctionCall 来给 AI 投喂信息。
渐进式约束大模型一般规则 → 具体限制 → 异常处理由浅入深让大模型先能解决大部分问题再优化部分特殊场景证据链要求避免 AI 生成代码必须展示原始数据和具体示例否则大模型可能会生成出来根本不存在的代码进行分析最终给出错误的结论标准化错误预设错误场景和统一回复模板否则大模型会产生幻觉基于错误信息继续分析给出错误的结论核心编写公式Prompt 角色身份 工具约束 执行流程 质量控制 输出规范
角色定位你是一个[专业领域]的[具体职位/专家] 用户会给你[具体输入格式]请你[具体任务目标]
工具约束✅ [工具名][允许场景] ❌ 禁止[具体操作]必须中止并报错[标准错误回复]
执行流程
[步骤名]使用[工具]获取[内容] * 若[条件A]则[操作A] * 若失败终止并返回[错误说明]
[下一步]...
质量控制⚠️ 一旦[条件]确认为[结果]后续不得声称为[矛盾结果] 判断条件必须同时满足 - [条件1] [条件2] [条件3]
输出规范输出内容须包含[要素1] [要素2] [要素3] 格式要求[具体格式]避免[不当格式]实际案例SQL 注入漏洞审核员 Agent Prompt
角色定位你是一个精通 SQL 注入漏洞分析的 SAST 白盒漏洞审核专家。
用户会给你发送一个漏洞 hash例如 1a223fbee9xxxxxxxxx请你完整分析该漏洞是否真实存在
工具约束为了明确 AI 能够获取到对应的 FunctionCall 以及 MCP Tool最好显式的在Prompt 中声明好能够调用的工具。
如果有必要也可以把具体的 FunctionCall Name 在 Prompt 中写明。
例如
工具使用规范必须严格遵守
工具说明 * ✅ SAST 工具只能获取 SARIF 中记录的调用链文件内容。
* ✅ GitLab 工具可任意访问 GitLab 仓库中的 Java 源码文件base64 编码用于获取字段类型与白名单校验逻辑。
在实际的使用中SAST 工具无法获取漏洞调用链意外的代码文件内容需要通过 Gitlab MCP 工具来获取所以我们添加如下工具约束* ❌ 禁止使用 SAST 工具获取 SARIF 中未出现的 Java 文件路径内容如 model、dto、entity 等类文件此行为为审核流程错误必须中止并报错 请返回简洁错误说明如 审核流程错误尝试使用 SAST 工具获取 SARIF 中未记录的文件路径内容请改为使用 GitLab 工具。
以上 Prompt 在实际使用中在大部分情况下是不会返回“审核流程错误”的但的确会规范 Agent 使用 Gitlab MCP 去获取 SAST 获取不到的代码内容。
执行流程明确 SQL 注入审核员的主要审核思路例如
质量控制这一步主要是告诉大模型到底什么样的条件下存在安全漏洞例如漏洞成立条件必须同时满足 * 污点参数来自用户输入 * 参数类型为字符串 * 参数用于 SQL 中 ${} 拼接 * 未经过白名单或强校验过滤在实际使用测试中我们发现如下问题当污点参数为自定义对象属性时大模型不会去关注污点参数是该对象的哪个属性导致误判污点参数。
当污点参数为自定义对象属性时SARIF 调用链中没有对应的dto声明文件导致大模型误判污点参数类型。
所以我们要添加一些限定的规范在部分步骤中例如获取污点参数字段类型 * 从 source_json 中提取污点参数例如 searchBox.period * 若为对象属性获取其类定义源码文件 * 获取路径策略如下 * 优先尝试 SARIF 中路径 * 若无使用 GitLab 工具根据包路径和以下顺序尝试 dto → model → entity → po → vo → request → query * 若路径不确定则根据 import 或 package 名计算合理路径 * 若多次尝试仍未获取到 Java 文件内容必须终止审核并返回简洁错误说明 未成功获取污点参数对应的源码文件无法确认字段类型审核失败。
* ⚠️ 一旦字段类型通过 GitLab 工具确认为 String后续分析中不得声称其为“整数”、“整型”或“数值类型”否则中止审核并返回 审核流程错误污点参数类型前后判断矛盾请重新确认类型并重新审核。
输出规范这里主要是让大模型按照我们想要的格式输出内容多 Agent 的情况下我们要让他更加详尽的输出漏洞详情在实际使用中要注意判断大模型是否有自己“生成”代码去分析而不是根据实际代码分析若有“生成”代码的情况则需要调整对应的 prompt。
返回内容格式要求 请你输出详细且条理清晰的漏洞分析报告内容须包含 * 漏洞基本信息和上下文描述 * 污点参数名称及类型说明 * SQL 拼接方式及对应 SQL 原文展示 * 白名单或过滤逻辑的存在与示例代码 * 对漏洞存在与否的专业分析理由 * 漏洞原理及危害说明如存在 * 修复建议如存在。
请以中文 Markdown 格式详细书写分析报告避免 JSON、YAML 或其他结构化格式。
如果流程遇到错误请直接给出简洁错误说明即可。
报告应严谨专业方便后续人工或自动化处理。
汇总分析终审 Agent提炼 Markdown 审核报告为标准结构化 JSON判断是否存在漏洞has_vul、生成审核备注remark、漏洞描述description、修复建议repair_suggestion字段结果将被用于工单系统自动创建。
关键工具与技术实现
数据标准化将 SAST 工具输出的漏洞结果统一转换为国际通用标准静态分析结果交换格式SARIF。
这确保了漏洞数据的可读性、可交换性并为后续的 Agent 分析提供了统一的数据源。
LLM 能力DeepSeek-V3 作为核心推理引擎支持漏洞理解、上下文分析与报告生成通过 Prompt Engineering 精准限定 Agent 行为。
Agent 工具化提供 SAST MCP查询 SARIF 数据与调用链提供 GitLab MCP用于字段类型与校验逻辑确认。
Prompt Engineering每个 Agent 拥有独立 System Prompt明确分析步骤、判断逻辑与输出格式要求提升审核一致性与准确性。
工作流编排使用 n8n 管理 Agent 调用、信息路由与数据解析
成效与落地成果该系统建成以后我们使用 AI 对 Qunar 历史存量的白盒漏洞进行了自动化审核与人工审核结果的一致率达到
9
36%经过 6 个多月的部署与验证Multi-Agent 白盒漏洞审核系统已在去哪儿网正式上线运营并取得显著成果漏洞审核效率提升单个漏洞审核缩短至
分钟内白盒漏洞运营全面 AI 化人工仅需花费少量时间确认 AI 审核忽略的漏洞防止漏报AI 自动生成漏洞描述和修复建议自动创建工单实现真正意义上的白盒漏洞审核闭环。
AI 驱动的 SDLC 白盒漏洞管理实践基于前述 Multi-Agent 白盒漏洞审核系统
9
36%的高准确率表现我们建立了一套基于 AI 判断结果的差异化处理策略AI 判断为漏洞的直接自动推送工单AI 判断为非漏洞的由人工进行二次确认。
该策略既能快速响应真实漏洞又通过人工复核降低漏报风险。
在此基础上我们进一步构建了从开发到上线的全流程 AI 漏洞管理闭环形成了如下的白盒漏洞处理流程AI 的加入给我们的 SDLC 白盒运营工作带来了如下变化
人工审核为主 → AI 主审 人工兜底审核能力智能化升级白盒审核作为 SAST 流程中最“吃人工”的环节一直以来严重依赖安全工程师逐条分析漏洞工作重复且效率瓶颈明显。
随着我们引入基于 Prompt 驱动的多智能体架构AI 逐步承担起审核主体职责并实现了准确率与可解释性的双重突破。
审核能力转变 通过将漏洞审核流程标准化建模为“任务调度 → 漏洞解析 → 报告输出 → 汇总判断”AI 智能体得以像一位资深安全工程师一样自动提取调用链、识别污点参数、判断白名单逻辑并输出结构化结论。
流程机制优化 我们设计了“AI 审核为主 人工审核为辅”的差异化流转策略AI 判断漏洞真实存在的直接自动生成工单推动修复AI 判断为非漏洞的再进入人工二次确认流程确保漏报风险最小化。
带来的变化 这一策略显著降低了人工审核负载使得安全团队的角色从“执行者”转变为“复核者”和“策略制定者”实现了漏洞审核工作的智能升级。
上线前安全卡点 → Beta 阶段前移拦截推动安全左移落地在传统流程中由于审核人力紧张SAST 常常被迫安排在上线前统一执行。
这种“卡点式检测”模式容易造成修复时间紧张甚至出现“已知带病上线”的风险。
而 AI 审核效率的提升为我们实现漏洞检测左移创造了技术前提。
流程触发前移 我们将 SAST 的触发时机由“上线打包前”前置到“Beta 发布阶段”即每次 Beta 部署后系统即自动扫描代码、完成 AI 审核并生成结构化结果。
研发团队在开发流程中就能第一时间收到可操作的漏洞修复建议。
研发协同增强 相比于以往“安全滞后通知”如今的 AI 审核结果在 Beta 当天便以工单形式触达开发极大缩短了响应周期也提升了安全在研发视角中的“原生集成感”。
带来的变化 我们不再是“上线前修补”而是真正做到“上线前消灭”问题。
这一改变让安全左移不再是一句口号而成为可以落地、持续执行的闭环机制。
白盒试点成功 → 智能体能力横向复用拓展安全自动化边界白盒漏洞审核是智能体体系最早落地的场景也是我们验证“AI 能否完成专业安全判断”的关键试点。
随着系统在该场景中稳定运行我们开始探索其能力在更广泛安全任务中的复制与复用。
智能体逻辑迁移我们将“结构化输入 → 多轮分析 → 判断决策 → 标准化输出”的智能体架构迁移到了告警运营与安全响应等场景。
AI 可以自动分析原始告警上下文、合并重复信息、评估可信度也可以在应急场景中提取日志中的 IOC、判断风险资产并自动触发处置流程。
Prompt 体系复用之所以能快速迁移是因为我们从白盒审核中沉淀了一套完整的 Prompt 工程体系。
每个 Agent 的角色定位、执行步骤、工具约束和输出格式都是标准化的仅需调整上下文和调用接口就能适配新的安全任务。
带来的变化AI 不再只是“审核专家”而逐步演变为“通用安全助手”。
我们正从“一个场景跑通”迈向“多场景联动、统一架构”的 AI Native 安全运营体系。
总结去哪儿网构建的 Multi-Agent 白盒漏洞智能审核系统是应对 SDLC 中 SAST 漏洞运营挑战的一次创新性尝试。
通过将 AI 智能体技术深度融入安全审核流程我们实现了从人工密集型向智能驱动型的转变有效解决了传统 SAST 工具误报率高、审核效率低、难以规模化等痛点。
更重要的是我们构建了从漏洞发现、审核、修复到复测的完整 AI 驱动闭环实现了真正意义上的无人值守安全运营。
这不仅大幅降低了运营成本也为企业的敏捷开发与快速迭代提供了更加可靠的安全保障。
未来我们将持续优化 Agent 的智能体能力扩展漏洞覆盖类型并探索更深度的与 DevOps 流程集成进一步提升软件开发的安全防护能力推动安全运营向更加智能化、自动化的方向发展。