2. GitLab安全治理基础
在开始配置任何扫描器之前，必须先建立一张清晰的“威胁地图”：攻击者究竟从哪些位置进入、利用什么条件、最终能造成什么后果。GitLab 的安全治理对象并不只是代码本身，而是从源码仓库一路延伸到运行容器的完整供应链。依赖与容器镜像之所以成为重点，是因为它们大量来自外部、版本迭代频繁、且往往以“可信组件”的身份被直接引入生产环境。
一、威胁模型：三个入口与一条传播链
从 GitLab 的视角看，依赖与镜像的威胁可以归纳为三个入口。第一是源码依赖入口：package.json、pom.xml、requirements.txt、go.mod 等清单文件声明的第三方包，可能本身带有已知漏洞，也可能被投毒（如 typosquatting、依赖混淆）。第二是构建产物入口：CI 流水线在构建阶段拉取的镜像基础层、构建工具、缓存，若来源不可信或未固定摘要，就可能被替换。第三是运行时入口：容器启动后加载的配置、密钥、挂载卷，以及镜像中残留的调试工具、默认口令、暴露端口。
这三个入口并非孤立，而是通过一条传播链放大风险：一个存在漏洞的依赖被编译进应用 → 打包进镜像 → 推送到镜像仓库 → 被部署到集群 → 在运行时被利用。因此，治理点必须覆盖“依赖清单 → 构建 → 镜像 → 运行时”整条链路，而不是只在某一环做扫描。
二、常见漏洞类型：从 CVE 到配置缺陷
已知 CVE 类漏洞是最容易被扫描器发现的一类。以 Log4Shell（CVE-2021-44228）为例，它出现在 log4j-core 2.0-beta9 至 2.14.1 版本中，攻击者通过 JNDI 注入即可远程执行代码。治理时不能只看“是否存在该版本”，还要判断该依赖是否被实际调用、是否暴露在外部输入路径上。GitLab 的依赖扫描会输出漏洞 ID、严重级别、受影响版本与修复版本，但最终定级需要结合可达性分析。
镜像层漏洞来自基础镜像和系统包。例如一个基于 debian:10 的镜像，其 apt 包可能包含数十个已知漏洞；而 alpine:3.18 的包数量少、攻击面小，但若使用 apk add 安装了过期组件，同样会引入风险。关键判断依据是：镜像中是否存在不必要的包、是否使用了 latest 标签、是否固定了镜像摘要（digest）。
配置与密钥类问题往往比 CVE 更隐蔽。例如在 Dockerfile 中写入 ENV DB_PASSWORD=...，或在 .gitlab-ci.yml 中明文传递令牌，都会导致凭证泄露。容器以 root 运行、挂载 /var/run/docker.sock、开启 privileged: true，则会在被突破后直接威胁宿主机。
许可证合规是常被忽视的一类。GPL/AGPL 类许可证具有传染性，若企业产品中静态链接了此类组件，可能被要求开源自有代码。治理动作是生成 SBOM（软件物料清单），并对照许可证策略进行拦截。
三、合规要求：把外部标准映射为流水线门禁
合规要求不是纸面文档，而应转化为流水线中的可执行门禁。常见的约束来源包括：OWASP Top 10（A06 易受攻击和过时的组件）、NIST SSDF（安全软件开发框架）、PCI DSS 6.3.3（要求及时修复高危漏洞）、以及等保 2.0 中对软件供应链安全的要求。落到 GitLab 中，通常体现为以下门禁规则：
- 依赖扫描发现
Critical或High漏洞时，流水线失败，禁止合并； - 容器扫描发现基础镜像存在高危漏洞时，阻断镜像推送；
- 密钥检测发现明文凭证时，立即告警并阻断；
- 许可证策略命中禁止清单（如 AGPL-3.0）时，要求人工审批。
.gitlab-ci.yml 或扫描策略中，避免人工判断造成不一致。四、一个可参考的治理基线示例
下面给出一个示例性的治理基线，用于把上述威胁模型和合规要求落到具体参数上。该基线属于教学示例，实际阈值需根据组织风险偏好调整。
| 治理对象 | 检查项 | 示例阈值 | 处置动作 |
|---|---|---|---|
| 依赖清单 | Critical/High CVE | Critical=0，High≤0 | 阻断合并 |
| 依赖清单 | 许可证命中禁止清单 | AGPL-3.0、SSPL | 人工审批 |
| 容器镜像 | 基础镜像高危漏洞 | High=0 | 阻断推送 |
| 容器镜像 | 是否固定 digest | 必须固定 | 告警并阻断 |
| 运行时配置 | 特权模式 / root 运行 | 禁止 | 阻断部署 |
| 密钥 | 明文凭证检测 | 命中即告警 | 阻断并轮换 |
需要强调的是，扫描结果本身不等于治理完成。一个漏洞从“被发现”到“被修复”，中间还涉及定级、分派、修复、复扫和关闭。GitLab 的漏洞管理界面会记录状态流转，但真正决定治理效果的，是团队是否把“修复时限”和“复扫验证”纳入日常流程。例如，Critical 漏洞要求 24 小时内修复，High 要求 7 天内修复，修复后必须重新触发流水线确认漏洞消失，才能关闭对应议题。