在安全左移已经成为研发共识的今天，团队不再担心"发现不了漏洞"，而是担心"漏洞来得太密、读得太多、跟得太慢"。一次合并请求可能触发十几个 SAST 高危提示，安全分析师要把每条提示翻译成"它意味着什么、谁需要修、怎么修才合理"，研发工程师则要花上数小时去理解一段从未接触过的代码为什么会触发告警。当这条链路上的任一环断了，安全积压就会越积越深。
极狐GitLab Duo 围绕这条链路提供了一组 AI 辅助能力：先用自然语言把漏洞讲清楚，再用置信度分数帮你筛掉可能的误报，最后让 AI 直接给出可合并的修复建议。它并不取代安全工程师和开发者，而是把"翻译"和"出方案"这两件最耗时的事从人手里接过来。
01 Duo 漏洞解释：把"机器告警"翻译成"工程师能读的说明"
极狐GitLab Duo 漏洞解释（Vulnerability Explanation）是一项通过大语言模型帮助团队处理 SAST 漏洞的能力，官方在 GitLab 16.0 引入，17.2 正式发布。它解决的核心问题不是"发现漏洞"，而是"理解漏洞"。
根据官方文档，AI 解释可以为单个漏洞产出三方面信息：
- 漏洞摘要：用简洁语言说明该漏洞的成因与可能后果，避免开发者直接啃 CWE 定义。
- 利用方式与影响：帮助理解攻击者可能的利用路径，以及一旦被利用会带来的影响。
- 建议的缓解措施：给出与项目语言和漏洞类型相匹配的修复方向。
在 JihuLab.com 上，这项能力默认由国内 SOTA 大模型提供支持。私有化部署形态下，也可以接入自部署的极狐GitLab Duo 模型，让数据不出域。
三个使用入口
漏洞解释的入口设计遵循"哪里发现、哪里解释"的原则，官方文档列出三种触发方式：
- 漏洞详情页文字链接：在漏洞描述下方会显示"你也可以通过询问极狐GitLab Duo Chat 来使用 AI 解释此漏洞并提供建议的修复方案"，点击即可调用。
- 通过合并请求解决下拉菜单：在漏洞详情页右上方的"通过合并请求解决"下拉列表中，选择"解释漏洞"。
- 极狐GitLab Duo Chat 命令：在 IDE 或 Web 端的 Duo Chat 中使用
/vulnerability_explain命令，针对当前上下文中的漏洞生成解释。
响应结果会显示在漏洞详情页的右侧，无需切换页面。三种方式都共享同一份后端能力，区别只在于触发场景。
前置条件
要使用漏洞解释，需要满足：
- 项目角色：开发者、维护者或所有者。
- 极狐GitLab Duo 已在群组或实例启用。
- 漏洞必须来自 SAST 扫描器（极狐GitLab 内置分析器或正确集成的第三方 SAST 工具）。
02 SAST 误报检测：先帮安全团队减负
漏洞解释解决了"看得懂"的问题，但在企业级 SAST 流水线里，团队更常面对的是"看不完"。一个中大型项目每周可能产生上百条高危提示，其中相当一部分是误报或低优先级噪声。如果每条都人工排查，安全团队会被淹没在工单里。
极狐GitLab Duo 的 SAST 误报检测（False Positive Detection）正是为此设计的。这项能力在 GitLab 18.7 引入测试版，18.10 正式发布，目标是让 AI 在每条严重和高严重性 SAST 漏洞上自动给出"它是不是误报"的判断。
AI 给出的三件东西
每次误报检测运行后，漏洞报告会更新以下信息：
- 置信度分数：一个 0–100 的数值，量化 AI 认为该发现是误报的可能性。
- 解释：基于代码上下文和漏洞特征，给出 AI 是如何推理出"是 / 不是误报"的简短说明。
- 视觉徽章：漏洞报告中显示一枚误报评估徽章，方便扫描时一眼识别。
置信度分数被划分为三档：
- 80–100%：可能是误报。AI 高度确信，可作为解除漏洞的强参考。
- 60–79%：可能为误报。AI 有合理信心，但仍建议人工确认。
- 低于 60%：不太可能是误报，强烈建议在解除前手动审查。
自动与手动两种触发
误报检测既支持自动运行，也支持手动触发：
- 自动：当 SAST 扫描在默认分支上完成、且结果中包含严重或高严重性漏洞、并已为项目启用极狐GitLab Duo 功能时，分析会在后台自动运行，无需人工介入。
- 手动：在漏洞详情页右上角选择"检查误报"，可对已有漏洞立即触发一次 AI 分析。
这种"自动打底 + 手动复查"的组合，让团队既不必为每条漏洞都付出处理成本，又能在关键节点保留人工介入空间。
启用与配置
误报检测默认关闭。启用流程分两步：
- 群组层允许基础流程：进入"设置 > 极狐GitLab Duo"，在"允许基础流程"下勾选"SAST 误报检测"。
- 项目层开启：进入项目"设置 > 通用 > 极狐GitLab Duo"，打开"开启 SAST 误报检测"开关。
同时还需要确保已在用户偏好中设置默认的极狐GitLab Duo 命名空间，并使用 GitLab 18.7 或更高版本。
03 漏洞修复：让 AI 直接生成可合并的修复
如果说漏洞解释解决"看得懂"、误报检测解决"过滤得掉"，那么漏洞修复（Vulnerability Resolution）解决的就是"修得快"。这项能力可以直接基于 SAST 结果生成一个合并请求，把建议的修复以代码改动形式呈现出来。
根据官方文档，漏洞修复覆盖一组经过自动化系统和安全专家共同验证的 CWE 类型，包括常见的 CWE-78（操作系统命令注入）、CWE-89（SQL 注入）、CWE-79 / CWE-80（XSS）、CWE-352（CSRF）、CWE-611（XXE）、CWE-295 / CWE-297（证书校验问题）、CWE-200 / CWE-209（敏感信息泄露）、CWE-330 / CWE-338（弱随机数）等。完整列表见 使用 AI 解决漏洞 文档。
两种工作流
漏洞修复在两个场景中可用：
场景一：从漏洞报告发起。在漏洞报告页筛选"活动 > 极狐GitLab Duo (AI) > 漏洞修复可用"，对支持修复的漏洞（带有蓝色图标）选择右上角"使用 AI 解决"，AI 会自动打开一个包含修复建议的合并请求。需要注意的是，公开项目会通过该 MR 公开发布漏洞及修复方案，敏感场景下建议先创建私有派生再生成。
场景二：在合并请求上下文中修复。从 GitLab 17.11 起，漏洞修复在 MR 中默认开启。当一个合并请求引入了支持修复的漏洞时，受影响发现会带有"狸猫 AI 图标"标识。打开安全发现对话框后选择"使用 AI 解决"，AI 会直接在当前 MR 提交一条建议评论。这种"在代码进入主干前就修掉"的方式，比事后回到报告页修复更贴近研发节奏。
完整闭环示例
把三件事串起来，可以形成这样一个工程化流程：
# .gitlab-ci.yml 中的安全扫描阶段 stages: - test - security sast: stage: security include: - template: Jobs/SAST.gitlab-ci.yml当 MR 推送到默认分支时，SAST 扫描会自动执行；扫描结果会同时触发：
- 误报检测：高危 SAST 漏洞自动获得置信度分数和徽章，安全团队据此优先关注非误报项。
- 漏洞解释：任何团队成员都可以对单条漏洞请求自然语言解释，快速判断它是否与本次改动相关。
- 漏洞修复：在 MR 上下文中，AI 可以直接为支持的 CWE 类型生成修复建议评论，开发者只需在合并前审查改动。
04 数据共享与责任边界
极狐GitLab Duo 的漏洞相关能力都明确披露了与第三方 AI API 共享的数据范围。漏洞解释会共享漏洞标题、漏洞标识符和文件名；漏洞修复会额外共享漏洞描述、CWE / OWASP 标识符，以及包含漏洞代码行的整个文件。
这意味着两类场景需要特别注意：
- 敏感业务系统：如果漏洞文件包含密钥、客户数据或受合规保护的内容，应优先使用私有化部署并接入自部署 AI 模型，确保数据不出域。
- 公开项目：漏洞修复在公开项目中会通过 MR 公开发布漏洞与修复方案，对攻击者来说是一份"已知弱点的修复指南"，需评估信息公开带来的副作用。
官方同时反复强调，AI 输出具有非确定性。漏洞解释的总结、误报检测的置信度、漏洞修复的代码改动，都应被视作"高置信度的初稿"，最终判断必须由安全工程师和开发者人工完成。审查 AI 建议时，至少需要确认两件事：
- 应用的现有功能没有被改动破坏。
- 漏洞确实按组织的安全标准被修复，而不是"看起来修了"。
05 实战建议：把 AI 漏洞分析接进工作流
把上述能力真正落到日常研发里，团队可以参考以下几条经验：
- 在 SAST 流水线中固定使用模板：通过
Jobs/SAST.gitlab-ci.yml模板把扫描作为默认阶段，让 AI 能力有"原料"可消费。 - 按置信度分流告警：把"80 分以上"的高置信误报交给值守同学批量处理，把"60 分以下"的项目交给安全工程师深度排查。
- 优先在 MR 中修复：相比事后回漏洞报告生成 MR，在 MR 上下文中修复可以让安全发现更早被发现，也更容易被开发者顺手处理。
- 保留 Human-in-the-loop：AI 解释与修复都应被视作"第一稿"，每个 MR 的合并门禁（合并列车 / Code Owner 审批 / 流水线门禁）仍然必须保留。
- 把 AI 能力纳入安全培训：让研发理解 AI 解释能告诉他们什么、不能告诉他们什么，避免出现"AI 说没问题就不看了"的错误使用方式。
写在最后
漏洞管理的真正瓶颈不是发现，而是从"被识别"到"被理解"再到"被修复"之间的那段距离。极狐GitLab Duo 在这三段距离上都给出了对应的 AI 能力：用自然语言解释漏洞、用置信度筛掉误报、用代码建议直接生成可合并的修复。它没有把安全工程师或开发者替换掉，而是把最耗时的"翻译"与"出方案"从他们手里接了过来。
接下来要做的，就是把这些能力嵌入到团队既有的 SAST 流水线、合并请求流程和安全评审规范里，让 AI 真正成为安全协作中的加速器，而不是又一个"看起来很酷但没人用"的开关。
安全工具的胜利，最终要看它有没有让工程师少加班一次、让漏洞少遗留一天。
