软件供应链安全扫描实战，极狐GitLab依赖扫描与漏洞治理
软件供应链安全扫描实战，极狐GitLab依赖扫描与漏洞治理
定义框：软件供应链安全扫描，指对应用依赖的第三方组件、容器镜像与构建产物进行自动化成分分析与漏洞比对，在漏洞进入生产环境前完成识别、分级与修复的过程。
你的代码可能只有几万行，但它跑起来依赖的第三方代码可能超过百万行。一个 npm 包、一个基础镜像、一个传递依赖，任何一个环节被投毒，攻击面就直接打进生产环境。近年多起供应链投毒事件反复验证同一件事：靠人工盯 CVE 公告，根本追不上披露速度。
更现实的问题是时效性。你在周一跑了扫描，一切正常；周三一个新漏洞披露，恰好命中你锁文件里的某个版本。如果扫描只在流水线里跑一次，这个漏洞要等到下次构建才会被看见。距离可能是一周，也可能是一个月。
这篇拆解极狐GitLab 在依赖扫描与漏洞治理上的官方做法：SBOM 为先的依赖扫描、容器镜像扫描，以及漏洞报告构成的治理闭环。所有功能名、参数、限制条件均出自极狐GitLab 官方文档中心。
一、依赖扫描：从"流水线扫一次"到"SBOM 为先"
极狐GitLab 的依赖扫描（Dependency Scanning）属于软件成分分析（SCA）范畴，可识别项目依赖中已知的安全漏洞，包括运行时、开发以及传递（嵌套）软件包。官方目前提供四种扫描方法，适用场景各不相同：
扫描方法 | 状态 | 触发方式 | 最适合 |
|---|---|---|---|
使用 SBOM 的依赖扫描 | 正式发布 | 流水线 | 新项目、以 SBOM 为先的工作流 |
持续依赖扫描 | 正式发布 | 安全公告数据库更新 | 无需重跑流水线即可捕获新披露漏洞 |
使用 Gemnasium 的依赖扫描 | 已弃用（17.9） | 流水线 | 等待迁移的现有项目 |
分析依赖的行为（Libbehave） | 实验 | 流水线 | 检测恶意软件包行为 |
两个关键时间点值得划重点：基于 Gemnasium 分析器的旧版依赖扫描在极狐GitLab 17.9 中已弃用，计划在 20.0 中移除。如果你们的流水线还在跑旧版模板，迁移要排上日程，官方提供了迁移指南。
新架构的思路是把"检测依赖"和"比对漏洞"拆开：
依赖检测：分析器解析锁文件或依赖关系图导出，生成 CycloneDX 格式的 SBOM（软件物料清单），作为作业产物保存；
漏洞比对：SBOM 通过依赖扫描 SBOM API 上传，扫描引擎将其与 GitLab 安全公告数据库和 GitLab 恶意软件公告比对，生成漏洞报告；
持续扫描：公告数据库一旦更新，默认分支最近一次成功流水线的 SBOM 会被重新扫描——新披露的漏洞无需重新运行流水线即可显现。
第三步就是前面那个时效性问题的官方答案。SBOM 存下来了，公告一更新就能回溯比对，不用等下次构建。
覆盖范围上，SBOM 依赖扫描支持的 PURL 类型包括 cargo、composer、conan、gem、golang、maven、npm、nuget、pypi、swift，主流语言基本全覆盖。以 Python 为例，支持 requirements.txt、Pipfile.lock、poetry.lock、uv.lock 等多种清单文件。
也有边界要知道：SBOM 扫描有每项目每小时 50 次的软性限流（不可配置）；默认只扫描根目录及直接子目录（深度 2）；恶意软件包发现仅在默认分支评估，严重性恒定为 Critical，标识符格式为 GLAM-<年份>-<月份>-<序号>——官方明确这类包的处置方式是移除软件包而非升级。
二、容器镜像扫描：基础镜像与操作系统包的兜底
依赖扫描管的是语言层依赖，容器镜像里的基础镜像和操作系统软件包由容器扫描（Container Scanning）负责，两者互补。官方将其归类为 SCA 的一部分，与 Trivy 集成执行容器漏洞静态分析（旧 Grype 分析器已不再维护，将于极狐GitLab 19.0 停止工作）。
启用只需一行模板引入，常用的几个 CS_ 变量如下：
变量 | 默认值 | 说明 |
|---|---|---|
|
| 要扫描的镜像，可指向外部仓库 |
|
| 严重性阈值，可选 LOW/MEDIUM/HIGH/CRITICAL |
|
| 设为 |
|
| 设为 |
|
| 单次扫描超时 |
一个最小可用的组合配置：
include:
- template: Jobs/Dependency-Scanning.v2.gitlab-ci.yml
- template: Jobs/Container-Scanning.gitlab-ci.yml
container_scanning:
variables:
CS_IMAGE: registry.example.com/team/app:latest前提条件：流水线需包含 test 阶段；私有化部署的 Runner 需使用 Linux/amd64 上的 docker 或 kubernetes 执行器。扫描完成后产出 gl-container-scanning-report.json 和 CycloneDX SBOM 产物 gl-sbom-report.cdx.json，漏洞详情包含 6 个严重性级别、CVSS 分数、EPSS 评分和 KEV（已知被利用漏洞）状态。
旗舰版还有一个容易被忽略的能力：容器镜像仓库的容器扫描。配置通知和软件包元数据数据库后，推送 latest 标签镜像会自动触发扫描，每个项目每天最多 50 次。也就是说，同一个镜像躺在仓库里，公告库更新后它也能被重新检出来。
三、漏洞治理闭环：报告、分诊与审计
扫出来只是第一步，堆在报告里的漏洞不会自己消失。极狐GitLab 的漏洞报告（旗舰版）提供项目或群组维度的汇总视图，治理动线大致是：
查看与筛选：按状态、严重程度（严重/高/中/低/信息/未知）、报告类型、扫描器筛选，支持按 OWASP Top 10 分组；CVE 类漏洞可直接查看 CVSS、EPSS、KEV 状态与可达性信息；
状态流转：漏洞状态在"需要分类、已确认、已忽略、已解决"之间流转，更改状态需安全管理员、维护者或所有者角色（极狐GitLab 17.0 起
admin_vulnerability权限已从开发者角色移除）；忽略留痕：忽略漏洞时必须选择忽略原因并填写评论，审计日志会记录忽略者、时间与原因——漏洞记录无法删除，永久留存；
关联处置：可将漏洞附加到已有议题或创建新议题，跟踪修复进度；部分漏洞支持通过自动化合并请求修复；
导出归档：支持导出 CSV，字段含 CVE、CWE、CVSS 向量、检测时间、位置等，可直接进合规汇报。
值得一提的是极狐GitLab Duo 的介入：漏洞报告的活动列会标识"漏洞修复"（有可用 AI 修复方案）与"误报检测"（Duo 已分析该漏洞是否为误报，悬停可看置信度评分和说明），分诊阶段的体力活可以交给 AI 先过一遍。
几句劝退的话也要说清楚：扫描器解决的是"已知漏洞"问题——组件有已知 CVE、镜像里有可识别的恶意包。它防不住自研代码里的逻辑漏洞（那是 SAST 的活），也防不住清单回退模式下的漏报（官方文档明示该模式无传递依赖、可能无法确定确切版本）。把扫描结果当成唯一安全指标，和完全不扫一样危险。
常见问题
Q1：旧版依赖扫描还能用多久，迁移要改什么？
基于 Gemnasium 分析器的依赖扫描在极狐GitLab 17.9 已弃用，计划在极狐GitLab 20.0 移除。迁移核心是把旧模板换成 Jobs/Dependency-Scanning.v2.gitlab-ci.yml，产物从漏洞报告为主转为 CycloneDX SBOM 为主，官方提供迁移指南，建议在合并请求中先行验证自定义变量避免误报。
Q2：依赖扫描和 SAST 有什么区别，都要开吗？
职责不同。SAST 扫的是你自己写的代码里的缺陷模式，依赖扫描（SCA）扫的是第三方组件的已知漏洞。供应链攻击大多从第三方依赖进来，两者互补而非替代，同一套流水线可以并行启用。
Q3：扫描结果怎么进合规审计？
漏洞报告支持一键导出 CSV，包含状态、CVE/CWE、CVSS 向量、忽略原因、检测时间等完整字段；忽略操作强制填写原因并记入审计日志，漏洞记录不可删除。这套留痕机制可直接对接等保或 ISO 27001 的漏洞管理审计要求。
企业级依赖与镜像扫描能力（SBOM 依赖扫描、容器镜像扫描、漏洞报告）属于极狐GitLab 旗舰版功能，开箱即用，无需自建扫描器集群。想评估现有项目的依赖风险面，可以预约产品演示，或前往极狐GitLab 文档中心查阅完整配置说明。也欢迎在评论区聊聊：你们的上次全量依赖盘点，是什么时候？
