安全扫描放在流水线里，比放在发布前更省成本
安全扫描放在流水线里，比放在发布前更省成本
在软件交付的生命周期中，有一个被反复验证的规律：漏洞发现得越晚，修复成本越高。
这不是什么新鲜理论。多年来，安全行业一直在讲"安全左移"（Shift Left），把安全检测尽量推到开发早期。但在实际落地中，很多团队的安全扫描仍然集中在发布前——临近上线，安全团队集中跑一轮扫描，然后丢给开发一份长长的漏洞清单。
结果是什么？发布延期，开发团队紧急返工，安全团队疲于奔命却总被抱怨"卡进度"。问题不在于安全扫描本身，而在于扫描发生的时间点和方式。
极狐GitLab 的做法是把安全扫描直接嵌入 CI/CD 流水线，让安全左移成为默认流程，而不是一个需要额外推动的倡议。
01 集中式安全扫描的三个问题
先看看"发布前集中扫描"这个模式为什么低效。
第一，修复成本随时间递增。 一个在编码阶段就能发现的 SQL 注入漏洞，开发者花几分钟就能修好。但如果是发布前才发现，开发者需要重新理解当时的代码逻辑，甚至需要切换分支、重建环境。如果漏洞已经进入生产环境，修复成本更是指数级上升——可能需要紧急发版、回滚、甚至通知客户。
第二，安全团队和研发团队割裂。 安全扫描跑在独立的环境里，结果以报告形式发给研发。漏洞描述、代码位置、修复建议分散在不同的工具和文档中，沟通成本高，跟踪困难。很多时候，漏洞报告石沉大海，不是因为研发不重视，而是因为流程太重。
第三，漏洞积压形成"安全债"。 集中扫描往往一次性产出大量发现，研发团队面对长长的清单容易产生"先上线再说"的心态。低优先级漏洞被搁置，逐渐积累成难以清理的安全债务。
这些问题的根源是同一个：安全扫描脱离了开发流程，变成了一个独立的、后置的环节。
02 流水线内嵌：安全扫描作为 CI/CD 的默认部分
极狐GitLab 在 CI/CD 流水线中内置了多种安全扫描能力。当代码提交或合并请求创建时，扫描作为流水线的一部分自动运行，安全发现直接显示在合并请求和 IDE 中，在代码合并前通知开发者。
这意味着安全检测不再是一个独立的"安检站"，而是开发流程中的"随行检查"。
极狐GitLab 内置的安全扫描能力包括：
SAST（静态应用安全测试）：在源代码投入生产环境之前发现漏洞。每次提交时自动扫描，支持 C/C++、C#、Go、Java、JavaScript、Python、PHP、Ruby、TypeScript 等主流语言。安全发现直接展示在合并请求中，包括新引入的漏洞和已解决的漏洞。
DAST（动态应用安全测试）：运行自动化渗透测试，模拟黑客攻击手法，检测 XSS、SQL 注入、CSRF 等运行时漏洞。完全语言无关，从外部对应用进行检查，可在流水线中运行或按计划执行。
依赖项扫描：识别项目依赖项（包括运行时、开发及传递嵌套软件包）中的已知安全漏洞。推荐使用 SBOM 方式——在流水线中生成 CycloneDX SBOM 产物，与极狐GitLab 安全咨询数据库比对。更强大的是持续依赖项扫描：当安全咨询数据库更新时，自动重新扫描最新流水线中的 SBOM 组件，无需重新运行流水线即可暴露新披露的漏洞。
密钥检测：监控代码中意外提交的密钥（私钥、令牌等），提供三层防护——推送时阻止密钥进入仓库、流水线中扫描默认分支和开发分支、议题和合并请求中保存前扫描。
容器扫描：扫描容器镜像中的已知漏洞，确保部署的镜像安全可靠。
这些扫描不是孤立的功能，而是围绕"检测—分类—分析—修复"的漏洞管理周期有机协作。
03 合并请求：安全发现的第一触点
把扫描放进流水线只是第一步。更关键的是，安全发现如何呈现给开发者。
极狐GitLab 的做法是把安全结果直接嵌入合并请求界面：
合并请求组件：在合并请求页面展示本次变更新引入了哪些安全发现、解决了哪些已有发现。开发者不需要去单独的安全平台查看报告，在提 MR 的时候就能看到。
变更视图内联注释：在合并请求的代码变更视图中，有安全问题的代码行会标记符号，点击即可查看问题详情。开发者可以在代码上下文中直接理解漏洞，不需要切换工具。
漏洞详情：每条发现包含描述（漏洞成因、影响和修复步骤）、严重性（六级分类）、位置（文件名和行号）、扫描器和标识符（CWE 标识符）。
这种设计让安全信息出现在开发者最自然的工作位置——合并请求界面。开发者不需要"主动去查安全问题"，安全问题会在他提交代码的时候主动找上来。
04 AI 加持：从"发现问题"到"修复问题"
发现漏洞只是第一步，修复才是最终目标。但在实际工作中，安全团队最大的痛点之一是误报——扫描器报了一堆问题，其中不少是"看起来像漏洞但实际不是"，安全分析师需要花费大量时间逐一甄别。
极狐GitLab Duo 在安全场景中引入了 AI 能力，帮助团队从"发现问题"走向"修复问题"：
SAST 误报检测流程：自动分析严重和高危 SAST 漏洞，识别可能的误报，为每项评估提供置信度评分和解释。安全团队可以把精力集中在真正的漏洞上，大幅减少手动分类时间。
SAST 漏洞修复流程：对于确认的漏洞，自动生成包含上下文感知代码修复的合并请求。利用多步推理，以最少的人工干预解决漏洞。开发者不需要从零开始写修复代码，AI 已经给出了建议方案。
密钥检测误报检测：自动分析密钥检测发现，识别可能的误报，提供置信度评分和解释。
这些 AI 能力的价值不在于"取代安全团队"，而在于把安全分析师从重复劳动中释放出来。当 AI 能够自动过滤误报、生成修复方案，安全团队就可以把精力放在威胁建模、架构安全和安全策略制定上——这些才是真正需要人类判断的工作。
05 漏洞管理周期：不是一次性检查，而是持续改进
安全不是一次性的检查，而是一个持续的循环。极狐GitLab 支持一个完整的漏洞管理工作流：
检测：通过流水线中的自动化安全测试识别漏洞。
分类：评估漏洞并确定优先级，决定哪些需要立即处理、哪些可以稍后处理。
分析：对已确认的漏洞进行详细分析，理解其影响并确定修复策略。
修复：修复漏洞的根本原因或实施风险缓解措施。
这个循环随着每次代码变更重复，使团队能够逐步改善应用安全态势。每次循环的结果都用于改进下一轮——比如调整检测规则以减少误报，或者根据修复经验更新编码规范。
更重要的是，所有安全活动都在同一个平台上进行，安全团队和研发团队看到的是同一份数据、同一个漏洞状态。不再有"安全说修了，研发说没收到"的沟通断层。
写在最后
把安全扫描放在流水线里，不是什么革命性的理念——"安全左移"喊了很多年。但理念落地的关键在于工具：扫描能力是否足够全面、结果是否足够精准、流程是否足够顺畅、修复是否足够高效。
极狐GitLab 把 SAST、DAST、依赖扫描、密钥检测、容器扫描内置到 CI/CD 流水线中，安全发现直接关联代码位置与责任人，再加上极狐GitLab Duo 的 AI 误报检测和自动修复能力，让安全左移从一句口号变成了默认流程。
当代码提交的那一刻起，安全扫描就已经在运行了。不需要等到发布前，不需要额外的安全平台，不需要长长的漏洞清单。发现问题、定位问题、修复问题——全部在同一个流水线里完成。
安全不是发布前的最后一道关卡，而是开发流程中每一步的随行守护。
