SAST 告警越扫越多，让安全智能体接手分诊与修复
SAST 告警越扫越多，让安全智能体接手分诊与修复
定义框：漏洞分诊（Vulnerability Triage）是指对扫描器产出的原始告警做确认、定级、去重与指派的过程，目标是区分「真实可利用的缺陷」与「扫描器误报」，并决定由谁、在什么时间窗口内修复。它不是扫描本身，而是扫描之后那道决定告警是否有价值的人工环节。
安全扫描器一旦接进流水线，告警量几乎必然增长。这不是工具选错了，而是扫描的覆盖面变广之后，原本藏在代码里的历史问题被一次性翻了出来。真正让团队崩溃的，往往不是"有漏洞"，而是"没人知道这批告警里哪些是真、哪些可以先放"。
于是出现了一种很典型的僵局：安全团队每周拉出几百条待处理项，研发团队认为是误报，两边各执一词，最后告警静静地躺在列表里，直到下一次合规检查时才被重新翻出。
为什么扫描告警会越扫越多
把扫描接入 CI 之后，告警增长通常来自三个方向，每一条的应对方式都不一样。
第一，存量问题集中暴露。 一个跑了三年的仓库第一次接 SAST，等于把三年的历史欠账一次性结算。这类告警的特点是量大、时间跨度长，但其中相当一部分位于早已不再调用的代码路径上。
第二，扫描规则在持续扩展。 扫描器的规则库会随版本更新，同一份代码在不同版本下给出的结果数量并不一致。这意味着告警数量增长，有时并不是代码变差了，而是判定变严了。
第三，依赖树在膨胀。 依赖扫描与容器扫描的结果会随着依赖数量线性增长，而且一个间接依赖引入的问题，往往会在多个项目里重复出现。
这三条叠加起来，就形成了一个让安全团队很难自证的局面：告警在涨，但没人能说清"涨出来的这部分里有多少是真实风险"。
分诊这件事，实际在做什么
把分诊拆开看，它其实只包含四个动作，而且每个动作都有明确的产物。
确认这条告警是不是真的。 扫描器基于模式匹配给出结论，天然存在误报。判断依据通常是：这段代码是否处在可达路径上、输入是否真的可被外部控制、是否有上游防护已经拦住。
判断真的话有多严重。 官方漏洞报告会给出 CVSS 评分与 EPSS 评分，前者描述理论严重性，后者描述被实际利用的概率。只看 CVSS 会让团队把精力花在"评分高但没人会走到"的分支上，只看 EPSS 又可能漏掉尚未被大规模利用的高危项。CVE 类漏洞还会标注 KEV 状态与可达性信息。
决定处理方式。 漏洞报告里的状态分为需要分类、已确认、已忽略、已解决四类，其中"已忽略"需要写明原因。真正需要警惕的是"已忽略"被滥用成永久搁置——一旦忽略不再附带理由，这个状态就失去了意义。
指派到人并追踪。 活动列会把每条漏洞关联的议题、合并请求、解决方案、误报判定都标记出来。换句话说，一条告警从"被扫出来"到"被关掉"的全过程，在产品里是有据可查的。
让智能体接手分诊，需要哪些前提
先看能力清单。极狐GitLab Duo Agent Platform 中与漏洞分诊直接相关的能力包括：安全分析师 Agent（自动执行重复性安全任务，排查议题、分析漏洞并生成修复）、SAST 误报检测任务流（自动识别并过滤 SAST 扫描中的误报）、SAST 漏洞解决任务流（自动为 SAST 漏洞生成修复和补救步骤）、密钥误报检测任务流（自动识别并过滤密钥检测结果中的误报）。其中 SAST 误报检测任务流属于已正式发布的功能，使用时会消耗极狐GitLab Credits。
再看启用条件。Agent Platform 的 Tier 为专业版与旗舰版，漏洞报告的 Tier 为旗舰版；使用前需要已开启极狐GitLab Duo，为顶级群组或实例开启相应版本。版本上有一个容易踩的坑：在极狐GitLab 18.9 及更早版本中，无法将 Agent Platform 与 Duo Enterprise 附加组件一起使用，需要升级到 18.10 或更高版本；另外 18.8 及更高版本默认已开启 Agent Platform，而 18.7 及更早版本需要手动开启测试版和实验性功能。
落地步骤：从"人工看列表"到"机器先过一遍"
第一步，把扫描触发时机收窄。 全量扫描跑得越频繁，无效告警越多。一个务实的做法是：合并请求事件只跑增量，默认分支才跑全量。
stages:
- test
sast_scan:
stage: test
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
variables:
SCAN_MODE: "diff"
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
variables:
SCAN_MODE: "full"
- when: never
script:
- ./scripts/run-sast.sh --mode "$SCAN_MODE"第二步，在漏洞报告里读智能体的判定结果。 进入项目的 安全 > 漏洞报告（需要安全管理员、开发者、维护者或所有者角色），活动列会给出几类关键图标：议题与合并请求表示已流转到具体处理人；误报检测图标表示极狐GitLab Duo 已分析过该漏洞是否为误报，鼠标悬停可以看到置信度评分和解释；漏洞解决方案图标表示存在可用的 AI 修复方案。
配合筛选器可以很快收敛范围：状态选"需要分类"，严重程度选"严重"或"高"，再在活动筛选器里选"极狐GitLab Duo 误报检测 → 误报"，就能直接拿到"智能体认为可以直接关掉"的那一批。
第三步，用 API 把确认动作脚本化。 漏洞 API 提供了确认与解决两个动作：
# 确认一条漏洞（已确认则返回 304）
curl --request POST \
--header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
--url "$CI_API_V4_URL/vulnerabilities/$VULN_ID/confirm"
# 解决一条漏洞
curl --request POST \
--header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
--url "$CI_API_V4_URL/vulnerabilities/$VULN_ID/resolve"把这两条接口接进每周的安全例会流程，就能把"会上讨论 → 会后有人去点"变成"会上讨论 → 会后脚本批量落状态"。注意权限不足时接口会返回 403 Forbidden，而不是静默失败。
五个容易踩的坑
坑 1：拿漏洞报告顶部的计数做汇报。 出于性能原因，当漏洞总数超过 1000 时，页面顶部会显示"1000+"而不是精确数字。这个上限只影响顶部计数，表格里仍然能查到全部漏洞，但如果你直接截图汇报，管理层看到的就是一个被截断的数字。
坑 2：把"归档"当成"已修复"。 在 JihuLab.com 上，漏洞在最后一次更新一年后会被归档。一条长期没人碰的告警会自己从列表里消失，这不代表它被解决了。定期导出才是可靠的留痕方式。
坑 3：把已弃用中的 API 当长期依赖。 官方漏洞 API 目前正在弃用过程中且不稳定，响应负载可能在不同版本间变化，官方建议使用 GraphQL API 代替。做批量脚本时，要么接受这个不确定性并加好校验，要么直接走 GraphQL。
坑 4：以为扫了分支就等于更新了报告。 漏洞报告展示的是默认分支的数据，针对非默认分支运行的流水线不会更新报告的时间戳。排查"明明扫过了为什么报告没变"时，先看分支。
坑 5：把"已忽略"用成垃圾桶。 忽略需要给出原因，从警告模式的安全策略中绕过违规时同样必须提供原因。缺少理由的忽略会让后续审计无法解释，也会让状态字段彻底失真。
什么情况下别这么做
智能体适合接手"量大、规则明确、判断路径可复现"的分诊工作，但下面几种情况不适合直接交给它：
涉及业务逻辑的漏洞。 安全审查任务流用于检测合并请求中的业务逻辑漏洞，但这类问题高度依赖业务上下文，机器给出的结论只能作为线索，不能作为结论。
合规口径需要人工签字。 等保、行业监管等场景下，责任主体必须是人，智能体的判定只能作为辅助材料。
团队还没有统一的状态定义。 如果"已确认""已忽略"在团队里没有一致标准，引入自动化只会更快地产出不可信的状态数据。
扫描规则本身尚未收敛。 规则库还在大幅变动时，先稳定规则再谈自动分诊，否则历史结论会被反复推翻。
常见问题
Q1：智能体判定的误报，可以直接关闭吗？
可以批量处理，但建议保留一次人工抽检。漏洞报告中的误报检测会给出置信度评分与解释，把低置信度的那部分单独挑出来人工复核，成本可控。
Q2：告警量已经很大了，先做哪一步？
先收窄触发时机（增量/全量分离），再按"状态=需要分类 + 严重程度=严重/高"做一次收敛，最后才考虑引入智能体。顺序反过来会让第一步的噪声直接灌进后续流程。
Q3：这套能力需要什么版本和版本组合？
Agent Platform 的 Tier 为专业版与旗舰版，漏洞报告为旗舰版。需要特别确认的是：18.9 及更早版本无法将 Agent Platform 与 Duo Enterprise 附加组件一起使用，需升级到 18.10 或更高版本。
想让安全告警真正闭环？ 从扫描到分诊到修复，极狐GitLab 把这条链路放在同一个平台里完成。查看 Duo Agent Platform 文档 了解安全类智能体的完整能力清单，或访问 极狐GitLab 官网 预约演示。
