在安全左移已经成为研发共识的今天团队不再担心发现不了漏洞而是担心漏洞来得太密、读得太多、跟得太慢。一次合并请求可能触发十几个 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-89SQL 注入、CWE-79 / CWE-80XSS、CWE-352CSRF、CWE-611XXE、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-loopAI 解释与修复都应被视作第一稿每个 MR 的合并门禁合并列车 / Code Owner 审批 / 流水线门禁仍然必须保留。把 AI 能力纳入安全培训让研发理解 AI 解释能告诉他们什么、不能告诉他们什么避免出现AI 说没问题就不看了的错误使用方式。写在最后漏洞管理的真正瓶颈不是发现而是从被识别到被理解再到被修复之间的那段距离。极狐GitLab Duo 在这三段距离上都给出了对应的 AI 能力用自然语言解释漏洞、用置信度筛掉误报、用代码建议直接生成可合并的修复。它没有把安全工程师或开发者替换掉而是把最耗时的翻译与出方案从他们手里接了过来。接下来要做的就是把这些能力嵌入到团队既有的 SAST 流水线、合并请求流程和安全评审规范里让 AI 真正成为安全协作中的加速器而不是又一个看起来很酷但没人用的开关。安全工具的胜利最终要看它有没有让工程师少加班一次、让漏洞少遗留一天。