周三下午三点，你喝完最后一口咖啡，GitLab 流水线全绿。构建通过，测试跑完，部署自动触发——完美。但你没看到的是，一个标注着“高危”的 npm 包也跟着进了生产环境。

CI 通过，只代表你配置的检查全过；它可不代表发布是安全的。这就是 GitLab CI 安全扫描必须存在的理由：依赖扫描、密钥检测、包审计，帮你把藏在开源组件里的漏洞拦在发布之前。

GitLab 的扫描能力按版本分级。Ultimate 用户享受全套定制：依赖扫描结果直接嵌入合并请求部件、漏洞报告页面、安全仪表盘；哪怕流水线跑完，你也能在 Merge Request 里就瞧见风险提示。Free 和 Premium 用户？也能跑，只是结果躺回了 CI 工件里，或者只是让流水线变红——没有那些花花绿绿的仪表盘。

怎么配？Ultimate 最简单，一行引用模板：include: - template: Jobs/Dependency-Scanning.gitlab-ci.yml。然后让流水线在测试阶段后面加上一个安全阶段，分析器会自动识别 package-lock.json、yarn.lock、composer.lock、poetry.lock、Pipfile.lock、go.sum、Gemfile.lock 等锁文件，连传递性依赖里的漏洞都给你揪出来。

等等，传递性依赖是啥？就是你的项目直接引用了 A 库，A 库又引用了 B 库，B 库有漏洞——只扫你的 package.json 是看不出来的。所以一定要扫锁文件或 SBOM（软件物料清单），让扫描器看清你的应用真正装了哪些东西。

如果你用的是 Free 或 Premium，别灰心，安全扫描照样跑。把 Trivy、OWASP Dependency-Check、npm audit、pip-audit、composer audit、cargo audit、gitleaks 等开源工具写进 CI Job 就行。它们能生成漏洞报告、让危险构建失败，甚至把报告上传——只是没有 GitLab 原生的 UI 集成，但你依然可以在构建日志里看到。

最后一句大实话：别因为没用 Ultimate 就跳过安全扫描。流水线变红总比生产环境爆雷要好。配置几分钟，省下的事后加班可不止几天。