第 4 章 · 05 CI/CD 集成

第 4 章 · 05 CI/CD 集成

本节摘要:Strix 跑在无头模式(-n/--non-interactive)里即可嵌入任意 CI/CD 流水线,在漏洞进入生产前拦截。本节讲清三件事:无头模式与 diff 范围(PR 风格 CI 运行自动只扫变更文件)、退出码作 CI 门禁(0=无漏洞通过、1=执行错误、2=发现漏洞阻断合并)、以及四大 CI 平台(GitHub Actions / GitLab CI / Jenkins / CircleCI)的开箱即用配置。重点推荐「PR 上 quick 模式 + 夜间 deep 模式」的双速策略,让安全检查既快又不拖慢迭代。所有平台都要求 runner 能访问 Docker。

内容来源:原项目文档 docs/integrations/github-actions.mdx 与 docs/integrations/ci-cd.mdx,汉化并合并。

⚠️ 仅限授权测试:CI/CD 集成扫描的是你自己的仓库;确保 LLM 密钥等敏感信息用各平台的 secrets 机制管理,不要硬编码进配置文件。

学习目标

阅读完本节,你应当能够:

1. 用 -n / --non-interactive 跑无头模式,并说明它为何适合 CI。
2. 用 --scope-mode diff / --diff-base 只扫变更文件,缩短 PR 耗时。
3. 用退出码 2 做 CI 门禁(发现漏洞即阻断合并)。
4. 写出 GitHub Actions 的最小工作流与所需 secrets。
5. 把 Strix 接入 GitLab CI / Jenkins / CircleCI 三大平台。
6. 设计「PR quick + 夜间 deep」的双速扫描策略。

一、无头模式:CI 的入口

CI/CD 是自动化流水线,没有人在屏幕前点 TUI。Strix 用 -n 或 --non-interactive 标志切到无头模式:

strix -n --target ./app --scan-mode quick
​

对 PR 风格的 CI 运行,Strix 会自动把 quick 扫描范围限定到变更文件。你也可以强制这个行为并显式设 base ref:

strix -n --target ./app --scan-mode quick --scope-mode diff --diff-base origin/main
​

💡 diff 范围是 CI 的关键:全量扫一个中型仓库可能要几小时,塞不进 PR 流程;只扫变更文件把耗时压到分钟级,让安全检查能跟上每次提交。--scope-mode auto 会自动判断是否在 CI/无头环境,通常无需手动设;diff 强制、full 禁用。详见第 2 章 CLI 参考的「深度类参数」。

⚠️ diff 解析失败的常见原因:CI 环境(尤其 shallow clone)缺少完整 git 历史,导致 merge-base 与分支比较无法解析。解决:fetch 完整历史(GitHub Actions 用 fetch-depth: 0),或显式设 --diff-base。

二、退出码:CI 门禁

无头模式下,Strix 用退出码表达扫描结果,可直接当 CI 门禁:

💡 门禁的核心是 2:退出码 2 = 「这次改动引入了可验证的漏洞」,直接阻断 PR 合并。配合 --scan-mode quick,即可在 PR 上做快速、聚焦的安全检查,把漏洞挡在生产之前。注意:交互模式始终退出 0,所以 CI 必须用 -n。

三、GitHub Actions

最常见场景:在每个 PR 上跑 Strix 安全扫描。

3.1 基础工作流

# .github/workflows/security.yml
name: Security Scan

on:
  pull_request:

jobs:
  strix-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install Strix
        run: curl -sSL https://strix.ai/install | bash

      - name: Run Security Scan
        env:
          STRIX_LLM: ${{ secrets.STRIX_LLM }}
          LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
        run: strix -n -t ./ --scan-mode quick
​

3.2 所需 secrets

在仓库设置里加这两个 secret:

⚠️ fetch-depth: 0 是关键:actions/checkout 默认 shallow clone(只拉最近一次提交),Strix 无法算 merge-base、diff 范围会解析失败。务必带 fetch-depth: 0 拉完整历史,或显式设 --diff-base。这是 GitHub Actions 上 Strix 最常见的坑。

3.3 退出码行为

工作流在发现漏洞时失败(退出码 2):0 通过、2 失败阻断合并。

四、其他 CI 平台

所有 CI 平台的接入套路一致:runner 能访问 Docker + 设好 STRIX_LLM/LLM_API_KEY 环境变量 + 跑 strix -n -t ./ --scan-mode quick。

4.1 GitLab CI

# .gitlab-ci.yml
security-scan:
  image: docker:latest
  services:
    - docker:dind
  variables:
    STRIX_LLM: $STRIX_LLM
    LLM_API_KEY: $LLM_API_KEY
  script:
    - curl -sSL https://strix.ai/install | bash
    - strix -n -t ./ --scan-mode quick
​

4.2 Jenkins

// Jenkinsfile
pipeline {
    agent any
    environment {
        STRIX_LLM = credentials('strix-llm')
        LLM_API_KEY = credentials('llm-api-key')
    }
    stages {
        stage('Security Scan') {
            steps {
                sh 'curl -sSL https://strix.ai/install | bash'
                sh 'strix -n -t ./ --scan-mode quick'
            }
        }
    }
}
​

4.3 CircleCI

# .circleci/config.yml
version: 2.1
jobs:
  security-scan:
    docker:
      - image: cimg/base:current
    steps:
      - checkout
      - setup_remote_docker
      - run:
          name: Install Strix
          command: curl -sSL https://strix.ai/install | bash
      - run:
          name: Run Scan
          command: strix -n -t ./ --scan-mode quick
​

⚠️ 所有 CI 平台都要求 Docker 访问:Strix 跑在 Docker 沙箱里,runner 必须能访问 Docker。GitHub Actions 的 ubuntu-latest 自带;GitLab 用 docker:dind;CircleCI 用 setup_remote_docker;Jenkins 的 agent 需装 Docker。Docker 不可用会直接退出码 1。

上图把无头模式、退出码门禁与双速策略串成一张图:PR 上 quick 模式做快速门禁(退出码 2 即阻断),夜间 deep 模式做全量覆盖,两者共同覆盖「快反馈」与「深排查」。

五、双速扫描策略:PR quick + 夜间 deep

不同场景需要不同深度。把三种扫描模式按节奏分配,既快又全:

💡 推荐策略:PR 上用 quick 模式保反馈快(只扫变更文件,分钟级);夜间定时跑 deep 模式做全量覆盖(1~4 小时,扫整库找深层漏洞)。这样既不拖慢日常迭代,又能定期做深度排查。

夜间 deep 扫描的 GitHub Actions 示例(在 PR 基础上加定时触发与全量范围):

# .github/workflows/security-nightly.yml
name: Nightly Deep Scan

on:
  schedule:
    - cron: "0 2 * * *"   # 每天凌晨 2 点

jobs:
  strix-deep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Install Strix
        run: curl -sSL https://strix.ai/install | bash
      - name: Run Deep Scan
        env:
          STRIX_LLM: ${{ secrets.STRIX_LLM }}
          LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
        run: strix -n -t ./ --scan-mode deep --scope-mode full --max-budget 50
​

⚠️ deep 模式务必配 --max-budget:deep 扫描耗时长、token 消耗大,不设预算上限可能在夜间跑飞。配合第 2 章的 --max-budget(无头模式达阈值 stopped 干净停止),让夜间扫描可控。

六、CI 集成排错清单

• 退出码 1 + 缺环境变量:确认 STRIX_LLM 与 LLM_API_KEY 已在 secrets 配置,且环境变量名拼写正确。
• 退出码 1 + Docker 不可用:runner 没装 Docker 或没权限;按各平台的 Docker 配置(dind / setup_remote_docker)检查。
• diff 范围解析失败:CI 用了 shallow clone;拉完整历史(GitHub fetch-depth: 0)或设 --diff-base。
• 退出码 2 但你认为是误报:无头模式下 2 表示「发现可验证漏洞」——Strix 的发现带 PoC,误报率低;先去 TUI/报告里看 PoC 再判断,而非直接当作扫描器误报忽略。
• 成本失控:deep/standard 模式不设预算会烧钱;所有 CI 任务都应配 --max-budget。

本节要点回顾

1. 无头模式入口:CI 用 -n / --non-interactive;PR 风格 CI 自动把 quick 扫描限定到变更文件,也可 --scope-mode diff --diff-base origin/main 强制。
2. 退出码门禁:0 无漏洞通过、1 执行错误需排查、2 发现漏洞阻断合并——2 是 CI 门禁的核心(交互模式始终退 0,故 CI 必用 -n)。
3. GitHub Actions:基础工作流 = checkout(fetch-depth: 0)+ 安装 + strix -n -t ./ --scan-mode quick;secrets 设 STRIX_LLM 与 LLM_API_KEY。
4. fetch-depth: 0 是关键:shallow clone 导致 diff 解析失败,这是 GitHub Actions 上最常见的坑。
5. 四大平台套路一致:GitLab CI(docker:dind)、Jenkins(credentials() + sh)、CircleCI(setup_remote_docker)——都是「Docker 可访问 + 设环境变量 + 跑无头扫描」。
6. 所有平台要求 Docker:Strix 跑在 Docker 沙箱里,Docker 不可用直接退 1。
7. 双速策略:PR 上 quick(分钟级,扫变更文件)、夜间 deep(1~4 小时,全量);deep 必配 --max-budget 防成本失控。

至此第 4 章完成。模型决定上限、编排决定逼近方式、工具决定每步能走多远、CI/CD 决定这一切能否自动化地挡在生产之前。下一章起,我们进入漏洞实战——第 5 章讲透注入与执行类(SQLi/NoSQLi/SSTI/RCE/XXE/...),第 6 章讲透访问控制与客户端类(XSS/CSRF/IDOR/SSRF/JWT/...)。