1. 课程导入与安全扫描全景

在传统研发流程中，安全往往被安排在版本发布前的最后一道关卡：代码写完了、功能测过了，才由安全团队做一次渗透测试或人工审计。这种“事后补救”的模式有两个致命问题——发现漏洞太晚，修复成本极高；安全团队成为瓶颈，研发节奏被拖慢。GitLab SAST（Static Application Security Testing，静态应用安全测试）要解决的正是这个结构性矛盾：把安全检测左移到代码提交和合并请求阶段，让开发者在写代码的同时就获得漏洞反馈。

理解 GitLab SAST 的定位，需要先看清它在 DevSecOps 全景中的坐标。DevSecOps 的核心主张是“安全即代码”，即安全策略、检测规则、合规要求都以代码化、自动化的方式嵌入 CI/CD 流水线。在这个体系里，安全能力被拆解为多个层次：SAST 分析源代码和基础设施即代码（IaC）中的缺陷；DAST 在运行中的应用上做动态探测；依赖扫描检查第三方库的已知漏洞；容器扫描检查镜像层；密钥检测防止凭据泄露。GitLab SAST 属于最左侧、最早介入的一环，它不需要应用部署完成，只要代码进入仓库就能开始分析。

GitLab SAST 的核心价值可以归纳为三点。第一是自动化与一致性：通过 CI/CD 流水线中的预置模板，每次提交都执行相同的扫描规则，不依赖个人经验，也不会因为赶进度而被跳过。第二是漏洞定位到行：扫描结果直接关联到具体的文件、行号和代码片段，开发者不需要在安全报告和代码之间来回对照。第三是与合并请求集成：扫描发现的问题可以以 MR 评论、流水线状态、安全报告的形式呈现，让漏洞在代码合入主干之前就被拦截。

从整体工作流来看，GitLab SAST 的运转可以拆成五个阶段。代码推送到仓库后触发流水线，SAST 分析器（Analyzer）在 CI 作业中启动，对目标语言进行词法、语法、数据流和控制流分析，生成原始扫描结果；随后 GitLab 将结果解析、去重、与历史基线比对，形成安全报告；报告中的漏洞按严重程度分级，并展示在合并请求、流水线安全标签页和项目安全仪表盘中；开发者根据报告修复代码，再次提交后触发新一轮扫描，形成闭环。这个闭环的关键在于“扫描—反馈—修复—复扫”的周期足够短，通常在一次 MR 的生命周期内完成。

上图把 GitLab SAST 的完整链路和 DevSecOps 的分层关系放在同一张视图里。上半部分是 SAST 自身的五阶段闭环：代码推送触发流水线，分析器执行扫描，结果被解析为安全报告，开发者修复后再次提交，形成持续循环。下半部分展示了 SAST 在 DevSecOps 安全能力中的位置——它是最靠左、最早介入的一层，与依赖扫描、密钥检测、容器扫描、DAST 共同构成纵深防御。图中特别标注了“安全门禁”这一环节：当高危漏洞未修复时，流水线可以配置为阻止合并请求合入主干，这是 SAST 从“建议”变为“约束”的关键机制。

要真正用好 GitLab SAST，需要理解它的技术边界。SAST 分析的是静态代码，不运行程序，因此它能发现注入类漏洞（如 SQL 注入、命令注入）、硬编码密钥、不安全的加密算法、路径遍历等问题，但无法发现运行时才暴露的逻辑漏洞或配置错误。它的准确率受规则集和语言支持程度影响，可能产生误报。因此在实际工程中，SAST 通常与依赖扫描、密钥检测配合使用，而不是单独承担全部安全检测职责。

本课程的学习路径按照“认知—配置—集成—调优—治理”五个层次展开。首先建立对 GitLab SAST 定位和工作流的整体认知；然后学习如何在 .gitlab-ci.yml 中引入 SAST 模板、配置扫描规则和排除路径；接着把 SAST 集成到合并请求流程中，配置安全门禁和审批规则；再深入分析器参数、规则集定制和误报处理；最后从团队治理角度，建立漏洞分级、修复 SLA 和安全度量体系。每一层都围绕一个可执行的目标展开，确保学完就能在真实项目中落地。

需要特别强调的是，GitLab SAST 不是“开启即安全”的银弹。它的效果取决于三个因素：扫描规则是否覆盖了项目使用的语言和框架；流水线配置是否在正确的阶段执行扫描；团队是否建立了漏洞修复的闭环流程。很多团队开启了 SAST 却发现“没什么用”，往往是因为扫描结果没有被纳入合并请求的评审流程，或者高危漏洞长期挂起无人处理。工具只是起点，流程和习惯才是安全左移真正落地的地方。