GitLab CI：解惑 SAST 与代码质量检测，并非一回事-CSDN博客

引言

在使用 GitLab CI/CD 的过程中，很多朋友会注意到其内置了强大的安全扫描功能，特别是 SAST（静态应用安全测试）。这引出了一个常见的问题：SAST 是否已经涵盖了对代码语法、坏味道（Code Smell）等质量维度的检测？或者，我们是否需要额外集成其他工具来保障代码的健壮性与可维护性？这篇文章将深入探讨这一主题，厘清 SAST 与代码质量检测的界限，并提供一套切实可行的实践方案。在这里插入图片描述

SAST vs. 代码质量：术业有专攻

首先，我们需要明确一个核心概念：SAST 和代码质量（Code Quality）是两个不同但互补的领域。将它们混为一谈，就像是要求一位安全顾问同时扮演架构师的角色，虽然偶有交集，但其核心职责与关注点截然不同。

SAST (静态应用安全测试)：其主要目标是“向内看”，通过分析源代码来发现潜在的安全漏洞。它关心的是诸如 SQL 注入、跨站脚本（XSS）、不安全的依赖库、硬编码的密钥等问题。SAST 是保障应用安全防线的第一道关卡。
代码质量检测：它的目标是“向外看”，更关注代码的工程质量。它检测的是代码的“坏味道”，比如代码重复、过长函数、高复杂度的模块、不符合团队规范的编码风格等。这些问题虽然不直接导致安全漏洞，但会严重影响代码的可读性、可维护性和团队协作效率，是技术债的主要来源。

因此，GitLab CI/CD 默认提供的 SAST 功能，其重点在于安全扫描，并不会对代码的语法风格或结构性问题进行深入分析。要实现全面的代码治理，我们必须主动引入代码质量检测工具。

GitLab Code Quality：集成代码质量分析的桥梁

幸运的是，GitLab 提供了专门的 Code Quality 功能来解决这个问题。它并非一个单一的工具，而是一个开放的框架，允许我们将各种静态分析工具的报告集成到 GitLab 的工作流中，尤其是在合并请求（Merge Request）的审查环节。

GitLab 的代码质量报告依赖于一个开放的标准，即 Code Climate 规范。这意味着，任何能够生成 Code Climate 格式 JSON 报告的工具，都可以无缝集成到 GitLab CI/CD 中。

下面，我们通过一个流程图来展示代码质量检测在 CI/CD 流程中的位置。
在这里插入图片描述

实践方案一：使用 GitLab 内置模板

对于许多标准项目，最快捷的方式是使用 GitLab 提供的 Code-Quality.gitlab-ci.yml 模板。它底层使用了一个封装了 Code Climate 引擎和多种插件的 Docker 镜像，能够自动检测项目语言并运行相应的分析器。

集成方式非常简单，只需在 .gitlab-ci.yml 文件中加入以下内容：

include:
  - template: Code-Quality.gitlab-ci.yml

code_quality:
  # 可以根据需要覆盖一些默认设置
  # 例如，只在合并请求的流水线中运行
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'

当流水线运行时，code_quality 任务会自动执行，并将结果以制品（Artifacts）的形式保存。GitLab 会自动解析这份报告，并在合并请求页面中以可视化的方式呈现出来。

实践方案二：集成自定义代码质量工具

虽然内置模板很方便，但在很多场景下，团队可能已经有自己偏好的工具，比如针对 Python 的 pylint、flake8，或者针对 JavaScript 的 ESLint。集成这些自定义工具同样简单。

核心步骤是：让工具输出 Code Climate 格式的报告。许多流行的 linter 都有现成的插件可以做到这一点。

以集成 ESLint 为例，步骤如下：

安装格式化插件：为项目添加 eslint-formatter-gitlab 依赖。
```
npm install --save-dev eslint-formatter-gitlab
```

修改 .gitlab-ci.yml：创建一个新的 job 来运行 ESLint，并指定输出格式。

eslint_code_quality:
  stage: test # 或者一个专门的 lint stage
  image: node:18 # 使用包含 Node.js 的镜像
  script:
    # 运行 ESLint，使用 gitlab 格式化器
    # 报告会自动保存到 gl-code-quality-report.json
    - npm ci
    - npx eslint "src/**/*.js" -f gitlab
  artifacts:
    reports:
      codequality: gl-code-quality-report.json
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'

在这个配置中，我们定义了一个名为 eslint_code_quality 的任务。它使用 Node.js 镜像，运行 eslint 命令，并通过 -f gitlab 参数告诉 eslint-formatter-gitlab 插件生成 GitLab 能识别的报告。最后，通过 artifacts:reports:codequality 关键字，我们将这份报告正式声明为代码质量报告。

这种方法的优势在于极高的灵活性，无论是 SonarQube、Checkstyle 还是其他任何分析工具，只要能找到或开发一个适配器使其输出 Code Climate 格式的 JSON，就能完美融入 GitLab 的工作流。

结论

回到最初的问题：GitLab CI/CD 的 SAST 并不包含代码质量检测。SAST 守护的是应用的安全底线，而代码质量检测则关乎项目的长期健康与团队的协作效率。它们是软件开发生命周期中相辅相成的两个关键环节。

大家的理解是正确的，为了实现全面的代码治理，确实需要自己动手集成代码质量分析工具。好在 GitLab 提供了强大而灵活的 Code Quality 框架，无论是利用其内置的 Code Climate 模板，还是集成团队现有的工具栈，整个过程都相当顺畅。将代码质量检测作为合并请求的强制检查项，能够有效地将技术债扼杀在摇篮里，是提升团队工程能力的重要一步。