别再裸奔了！手把手教你把安全扫描塞进 CI/CD 流水线

“安全”这俩字，说起来重如泰山，做起来却常常被“敏捷”和“效率”挤到角落里吃灰。尤其在 CI/CD 的世界里，代码像坐火箭一样嗖嗖嗖地发布，安全问题却可能像定时炸弹一样潜伏着，哪天心情不好就给你来个“惊喜”。

别慌！今天咱就来聊聊，怎么把安全扫描（SAST、DAST）这俩“门神”请进 CI/CD 流水线，让你的代码从此告别“裸奔”时代。

为啥 CI/CD 离不开安全扫描？

先来唠唠嗑，为啥非得把安全扫描和 CI/CD 绑在一起？

你想啊，CI/CD 讲究的是啥？快速迭代、持续交付！恨不得一天上线八百回。这种速度下，传统的安全测试方法根本跟不上趟。以前那种开发完再集中测试的模式，早就 out 了！

安全扫描就像给代码做“体检”，能及早发现各种安全漏洞和隐患。把安全扫描集成到 CI/CD 流程里，就相当于给代码的“生产线”加了一道“安检”，有问题的代码直接拦下，不让它“带病上岗”。

这么做的好处，那是明摆着的：

• 早发现，早治疗： 漏洞发现得越早，修复成本就越低。在开发阶段就把问题解决了，总比上线后被黑客攻击了再补救强吧？
• 安全左移： 把安全测试前置到开发阶段，让开发人员在写代码的时候就关注安全问题，这叫“安全左移”。
• 自动化，省心省力： 安全扫描工具可以自动运行，不需要人工干预，省时省力，还能避免人为疏忽。
• 持续保障安全： CI/CD 是一个持续的过程，安全扫描也应该持续进行，这样才能保证代码始终处于安全状态。
• 合规性要求： 很多行业都有安全合规性要求，比如支付行业的 PCI DSS。把安全扫描集成到 CI/CD 流程里，可以更好地满足这些要求。

SAST 和 DAST：左右护法

安全扫描主要有两大类：静态应用程序安全测试（SAST）和动态应用程序安全测试（DAST）。

• SAST (静态应用程序安全测试): 这位“侦探”不运行代码，而是直接检查源代码、字节码或二进制代码，找出潜在的安全漏洞。 就像医生看X光片，不需要病人跑跑跳跳。常见的 SAST 工具包括 SonarQube、Fortify SCA、Checkmarx 等。
• 优点： 可以在开发早期发现问题，覆盖面广，可以发现代码层面的各种安全漏洞，如 SQL 注入、跨站脚本（XSS）等。
• 缺点： 可能会有误报，需要人工 review 结果，不能发现运行时才能出现的漏洞。
• DAST (动态应用程序安全测试): 这位“黑客”会模拟攻击者的行为，对正在运行的应用程序进行测试，找出可利用的漏洞。就像医生让病人在跑步机上跑，看看心脏有没有问题。 常见的 DAST 工具包括 OWASP ZAP、Burp Suite、Acunetix 等。
• 优点： 可以发现运行时才能出现的漏洞，误报率较低，更接近真实攻击场景。
• 缺点： 需要应用程序能够运行，测试时间较长，不能发现代码层面的漏洞。

SAST 和 DAST 各有千秋，就像左右护法，最好结合起来使用，才能更全面地保障代码安全。

集成 SAST 到 CI/CD 流水线

把 SAST 集成到 CI/CD 流水线，其实没那么复杂。下面以 GitLab CI/CD 和 SonarQube 为例，手把手教你操作：

1. 安装 SonarQube 服务器： 你需要先安装一个 SonarQube 服务器，用来接收扫描结果并进行分析。SonarQube 提供了 Docker 镜像，安装起来非常方便。
2. 在项目中添加 .gitlab-ci.yml 文件： 这是 GitLab CI/CD 的配置文件，用来定义 CI/CD 流水线的各个阶段和任务。
3. 在 .gitlab-ci.yml 文件中添加 SAST 扫描任务：

stages:
  - test
  - sast
 
sonarqube-sast:
  stage: sast
  image: sonarsource/sonar-scanner-cli:latest
  variables:
    SONAR_HOST_URL: "http://your-sonarqube-server:9000" # 替换成你的 SonarQube 服务器地址
    SONAR_TOKEN: "your-sonarqube-token" # 替换成你的 SonarQube 令牌
  script:
    - sonar-scanner
  only:
    - merge_requests
    - master

这个配置文件的意思是：

• 定义了两个阶段：test 和 sast。
• 在 sast 阶段，创建一个名为 sonarqube-sast 的任务。
• 使用 sonarsource/sonar-scanner-cli:latest 镜像作为任务的运行环境。
• 设置 SONAR_HOST_URL 和 SONAR_TOKEN 两个环境变量，分别指定 SonarQube 服务器地址和令牌。
• 执行 sonar-scanner 命令，进行 SAST 扫描。
• 设置 only 条件，只在合并请求和 master 分支上触发 SAST 扫描。

4. 在 SonarQube 中查看扫描结果： 提交代码后，GitLab CI/CD 会自动触发 SAST 扫描。扫描完成后，你可以在 SonarQube 的界面上查看扫描结果，包括发现的漏洞、代码质量等信息。

这只是一个简单的示例，实际应用中可能需要根据具体情况进行调整。比如，你可以根据 SonarQube 的扫描结果设置质量门禁，如果代码质量不达标，就阻止代码合并。

集成 DAST 到 CI/CD 流水线

DAST 的集成稍微复杂一些，因为它需要应用程序能够运行。下面以 GitLab CI/CD 和 OWASP ZAP 为例，介绍一种常见的集成方式：

1. 准备测试环境： 你需要一个能够运行你的应用程序的测试环境，比如 Docker 容器。
2. 在 .gitlab-ci.yml 文件中添加 DAST 扫描任务：

stages:
  - test
  - dast
 
dast:
  stage: dast
  image: owasp/zap2docker-stable
  variables:
    TARGET_URL: "http://your-test-environment" # 替换成你的测试环境地址
  script:
    - zap-baseline.py -t $TARGET_URL -r report.html
  artifacts:
    paths:
      - report.html
  only:
    - merge_requests
    - master

这个配置文件的意思是：

• 定义了两个阶段：test 和 dast。
• 在 dast 阶段，创建一个名为 dast 的任务。
• 使用 owasp/zap2docker-stable 镜像作为任务的运行环境。
• 设置 TARGET_URL 环境变量，指定测试环境地址。
• 执行 zap-baseline.py 命令，进行 DAST 扫描，并将扫描结果保存到 report.html 文件中。
• 将 report.html 文件作为构建产物，可以在 GitLab CI/CD 的界面上查看。
• 设置 only 条件，只在合并请求和 master 分支上触发 DAST 扫描。

3. 查看 DAST 扫描结果： DAST 扫描完成后，你可以在 GitLab CI/CD 的界面上下载 report.html 文件，查看扫描结果。

这种方式的优点是简单易用，但是功能比较有限。如果你需要更高级的 DAST 功能，比如自定义扫描策略、认证扫描等，可以使用 ZAP 的 API 或其他 DAST 工具。

进阶玩法：更智能的安全扫描

除了基本的集成，你还可以玩出更多花样，让安全扫描更智能：

• 增量扫描： 只扫描本次提交修改的代码，而不是整个项目。这样可以缩短扫描时间，提高效率。SonarQube 支持增量扫描。

• 自定义扫描规则： 根据你的项目特点和安全需求，自定义扫描规则。比如，你可以定义一些规则来检查代码中是否包含敏感信息，或者是否使用了不安全的 API。

• 与缺陷跟踪系统集成： 将安全扫描发现的漏洞自动同步到缺陷跟踪系统，比如 Jira，方便开发人员跟踪和修复。

• 安全扫描结果可视化： 将安全扫描结果以图表的形式展示出来，更直观地了解项目的安全状况。很多安全扫描工具都提供了 API，可以方便地与其他工具集成。

• 安全扫描编排， 可以根据项目特点和需求，灵活组合不同的安全扫描工具和流程。比如，你可以在开发阶段使用 SAST，在测试阶段使用 DAST，在发布前进行渗透测试。

总结一下

把安全扫描集成到 CI/CD 流水线，是保障代码安全的重要手段。通过自动化安全扫描，可以及早发现并修复漏洞，降低安全风险，提高软件质量。记住：安全不是一次性的工作，而是一个持续的过程。让安全扫描成为你 CI/CD 流水线的一部分，让你的代码从此告别“裸奔”！

别再犹豫了，赶紧行动起来，给你的 CI/CD 流水线加上安全扫描这道“保险”吧！