GitLab 业务逻辑分析器早期开放后怎样补充模式扫描

GitLab 在 2026 年 10 月 20 日公布了 Business Logic Security Analyzer（业务逻辑安全分析器）的早期开放。它解决的不是“某段代码是否像危险写法”，而是“这个接口是否执行了本来应该执行的业务规则”：例如读取订单时有没有检查归属、管理员动作有没有检查角色、更新接口是否让用户顺手改了 role。

因此，最实用的接入方式不是把传统 SAST 换掉，而是在原有模式扫描旁边补一层业务意图分析。官方入口与配置说明见 https://docs.gitlab.com/user/application_security/business_logic_scanning/；早期开放资格、实例形态和模型可用性仍以 GitLab 的实际环境为准。

如果你已经有 SAST，先把业务逻辑分析器当作“授权关系和对象归属的补充扫描”：合并请求走 scan profile，默认分支全仓库走 Duo Chat 或 API，两个配置变量放在项目 CI/CD 设置里，而不是写进 .gitlab-ci.yml。

先把业务逻辑扫描放到 SAST 旁边

我第一次看这个能力时，最容易误判的地方是把它当成“更强的规则库”。GitLab 的官方解释更接近另一种分工：SAST 擅长找危险数据流和已知模式，业务逻辑分析器则读取整个仓库，建立入口、角色、记录归属和动作之间的关系，再判断 handler 是否落实了这些规则。

这解释了为什么下面三类问题可能逃过普通模式扫描：

• 接口拿到 order_id 后直接返回订单，却没有验证当前用户是否拥有这笔订单。
• 接口确认用户已登录，却没有继续确认他是否具备管理员角色。
• 更新接口把请求参数整体交给模型，导致用户可以修改自己的 role 或 is_admin。

这层补充的边界要说清楚：它不是对每一种业务规则都做形式化证明，也不代表出现一条 finding 就可以直接当成已确认漏洞。实际接入时仍要把报告当成安全团队的待分流输入，结合代码上下文和业务约束处理。

按扫描范围选择入口，再补上两个配置变量

最小配方可以拆成两条：需要跟着合并请求走，就给项目附加 business logic scan profile；需要看默认分支完整仓库，就从 GitLab Duo Chat 启动 Business Logic Security Scan，或者通过 API 启动。Duo Chat 的命令应只发送 flow 命令本身，不要在后面追加合并请求编号。

文档给出的关键范围差异如下：

项目设置里再看两个变量：

• BL_SCAN_EFFORT：可设为 low、standard 或 high。未设置或填写其他值时按 low 处理；级别越高，扫描越深，也会消耗更多 GitLab Duo Agent Platform 用量。
• BL_TARGET_FILES：用换行或逗号分隔要扫描的文件路径。它对非默认分支生效，并替换合并请求默认的变更文件范围；默认分支扫描时会被忽略。

这里有一个很容易踩的坑：这两个变量要在项目的 CI/CD settings 中以普通、未保护、环境范围为 * 的变量提供；写进 .gitlab-ci.yml，或者临时运行 pipeline 时传入，并不会改变业务逻辑扫描读取到的配置。

早期开放阶段，哪些限制要先写进采用清单

如果团队准备把它接进日常流程，我会先把下面四项写进采用清单，而不是直接把结果设成发布阻断条件：

1. 资格和版本：公告面向部分 GitLab Ultimate 的 GitLab.com 客户早期开放；文档同时列出 GitLab.com 与 Self-Managed，实际资格需要向管理员、account team 或 sales team 确认。
2. 触发条件：自动合并请求扫描依赖成功的 head pipeline；没有 CI/CD pipeline、流水线失败、fork 合并请求、机器人触发或被新提交替换的 merge train，不按普通 MR 场景处理。
3. 覆盖范围：定时扫描目前还不可用；MR 扫描是部分文件扫描，默认分支的完整扫描应使用 Duo Chat 或 API。大于 400 个文件或 diff 太大时，官方文档提示可能退回全仓库扫描。
4. 成本与复核：每次扫描都是 GitLab Duo Agent Platform session，会消耗 GitLab Credits；代码量或攻击面越大，消耗通常越高。报告进入 Vulnerability Report 后，再由安全团队做误报、修复优先级和回归处理。

对我来说，最稳妥的落地顺序是：先选一个有明确角色与资源归属关系的服务做全仓库扫描，再给日常合并请求附加 profile；看到结果后再决定是否提高 BL_SCAN_EFFORT。这样既能快速发现 SAST 不擅长的缺失授权，也不会因为早期能力的成本和误报边界，反过来扰乱现有流水线。

相关问题

业务逻辑扫描会替代 SAST 吗？

不会。SAST 继续负责传统的模式、数据流和危险 sink 识别；业务逻辑分析器补的是对象归属、角色和业务动作之间的意图缺口。

为什么默认分支不能用自动 MR 扫描代替？

自动 MR 扫描只看新增或修改文件，而且依赖成功的 head pipeline；要看默认分支的全仓库关系，应从 Duo Chat 或 API 启动完整扫描。

能不能把扫描安排到定时任务？

当前官方文档仍标注 scheduled scans 不可用，需要使用 Duo Chat 或 API 触发默认分支扫描。