SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场ci-security-scanning-with-strix

ci-security-scanning-with-strix

安全与审计

查看项目

更新于 10-16 07:30

技能介绍

本技能用于为 CI/CD 流水线添加 Strix 安全扫描，使每个 Pull Request 都能获得针对变更文件的 AI 渗透测试，并在发现经验证漏洞时阻断合并。文档给出两种闸门方式，可按环境选择或组合使用。

一、用途与两种模式

  1. 托管平台（推荐多数团队）：连接一次 GitHub/GitLab/Bitbucket 应用，Strix 即可审查每个 PR，无需工作流文件、无需 Runner、无需 Docker、无需 LLM 密钥。结果以 PR 评论发布，并进入团队仪表盘。适合希望零 CI 维护、集中追踪，或 Runner 不具备 Docker 的场景。
  2. 自托管开源 CLI（在自有 Runner 中）：作为流水线步骤执行 diff 范围扫描，完全运行在自有基础设施内，免费（自带 LLM 密钥），无需外部账号，要求 Runner 具备 Docker。适合隔离网络/自托管 CI，或不愿让扫描数据离开自有环境的场景。

两种方式都会在发现经验证漏洞时使构建失败，并输出 SARIF 2.1.0，因此可以先采用一种，后续再补另一种。

二、方式 A：在 Runner 中自托管开源 CLI 对每个 PR 执行 diff 范围扫描：只测试变更文件，quick 模式保持速度，发现经验证漏洞时退出码 2 使构建失败。

GitHub Actions 示例：创建 .github/workflows/security.yml，内容包含作业 strix-scan，运行于 ubuntu-latest，步骤依次为 actions/checkout@v4（需 fetch-depth: 0，用于 diff 范围解析）、通过 curl -sSL https://strix.ai/install | bash 安装 Strix、以环境变量 STRIX_LLM 与 LLM_API_KEY 运行 strix -n -t ./ --scan-mode quick --max-budget 10，以及“Fail unless the scan completed”步骤：取最新 strix_runs/*/run.json，用 jq 读取 .status，若不是 completed 则报错并退出 1。随后需提示用户添加两个仓库密钥：STRIX_LLM（模型 id，例如 openai/gpt-5.4）和 LLM_API_KEY（提供方密钥），不要自行创建这些值。

注意事项：在 CI/无头运行中 Strix 自动将范围限定为 PR 变更文件（--scope-mode auto）。若 diff 解析失败，保留 fetch-depth: 0，或将 --diff-base 设为 PR 的实际基础分支，在 GitHub Actions 中使用 origin/${{ github.base_ref }} 而非硬编码 origin/main。退出码：0 通过、2 发现漏洞（作业失败）、1 配置错误；可用 --fail-on high 仅在 high/critical 发现时失败，较低级别仍会报告，因此通过不等于无发现。Runner 需要 Docker（默认 GitHub 托管 Ubuntu Runner 已具备）。

预算建议：需为扫描预留足够预算，避免“失败开放”。退出 0 仅表示“在被分析范围内没有经验证的漏洞”；若在 diff 被完全覆盖前触及 --max-budget，扫描会提前结束并仍可能退出 0。上述“Fail unless the scan completed”步骤可缩小该缺口：当扫描在硬预算上限处被截断且没有最终报告时，strix_runs/<run>/run.json 为 stopped。但它不是完整防护——智能体在触及硬上限前会收到渐进式收尾警告，因警告而收尾的运行仍会调用 finish_scan 并记录 completed（覆盖不完整）。因此在任何用于合并闸门的流水线中保留该步骤，并给扫描真实余量（可将 run.json 的 llm_usage.cost 与 --max-budget 对比，若接近上限就提高预算）。快速 diff 范围 PR 扫描 --max-budget 10 通常足够，大 diff 需提高。

可选：将发现上传到 GitHub 代码扫描。Strix 将 SARIF 2.1.0 写入 strix_runs/<run>/findings.sarif，可用 github/codeql-action/upload-sarif@v3 上传，sarif_file 指向 strix_runs。

其他 CI 系统：任何流水线同理——安装、设置两个环境变量、无头运行。示例脚本先解析 PR 基础分支（优先使用 CI 的基础分支变量，如 GitLab 的 CI_MERGE_REQUEST_TARGET_BRANCH_NAME；否则用 git symbolic-ref 解析 origin/HEAD，再回退 main），组成 DIFF_BASE=origin/${BASE_BRANCH:-main}；若无法验证该 ref 则报错退出 1，避免静默缩小范围（例如退化为 HEAD~1，在多提交分支上只扫描最后一次提交而放过更早的提交）；随后执行 strix -n -t ./ --scan-mode quick --scope-mode diff --diff-base "$DIFF_BASE" --max-budget 10。以退出码作为流水线闸门（注意上述预算/失败开放风险，给扫描足够预算完成）。可将标准扫描安排在夜间，为发布候选执行深度扫描。

三、方式 B：托管平台（无需 Runner 基础设施） 无需工作流文件、Docker 或 LLM 密钥，三种用法：

  1. PR 审查应用（零代码）：用户在 app.strix.ai 仪表盘安装 Strix 的 GitHub/GitLab/Bitbucket 应用并为仓库开启 PR 审查。此后每个 PR 自动审查，发现以 PR 评论发布，仓库无需添加任何内容。这是最低投入路径，当用户只想要 PR 闸门时优先推荐。
  2. 从任意流水线以 CLI 触发：若要从现有流水线（或没有 SCM 应用的环境）触发，使用同一 strix 二进制，配合具备 pr_reviews:write 权限的令牌，将令牌存为 CI 密钥，并请用户在 Settings → API Access 创建。先用 strix cloud repos list 读取仓库的 provider 与 installation_id。GitHub Actions 步骤示例：条件为 github.event_name == 'pull_request'，环境变量 STRIX_API_TOKEN 取自密钥，步骤中安装 Strix 并执行 strix cloud pr-reviews start --provider github --installation-id "${{ vars.STRIX_INSTALLATION_ID }}" --repository-full-name "${{ github.repository }}" --pr-number "${{ github.event.pull_request.number }}"。当 stdout 不是终端时输出为 JSON，无 TTY 时无提示。若要按结果对构建设闸门，可轮询 strix cloud pr-reviews get <id> --json，在存在未解决的 critical 或 high 时失败。当流水线无法安装 CLI 时，也可直接使用原始 REST 端点 POST /api/v1/pr-reviews/start。
  3. 无 SCM 应用时的源码上传：将检出的代码树作为云端代码审查上传（需要 scans:write 与 uploads:write）。两步摘要交接让由人决定什么离开 Runner：先执行 strix cloud scans start --source . --dry-run --show-files --json 查看并记录 source.archive_sha256，再执行 strix cloud scans start --source . --approve-sha256 "$SOURCE_SHA256" --wait。 退出码：0 成功、4 认证或套餐限制、5 需要付费。非 Enterprise 扫描会消耗额度。

四、选择建议 多数团队推荐方式 B（无需维护、集中仪表盘）；当扫描必须完全留在自有基础设施内时使用方式 A。完整 CLI 覆盖范围（PR 审查、扫描、SARIF 导出、计划任务）见 managed-pentesting-with-strix 技能。