strix-ci-setup
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseSet up Strix in CI/CD
在CI/CD中配置Strix
You can gate PRs two ways — pick based on the environment, or combine them:
- Managed platform (recommended for most teams) — connect the GitHub/GitLab/Bitbucket app once and Strix reviews every PR with no workflow file, no runner, no Docker, and no LLM key. Results post as PR comments and land in the team dashboard. Best when you want zero CI maintenance, central tracking, or your runners lack Docker. See "Managed platform" below and the strix-cloud-api skill.
- Self-hosted OSS CLI in your runner — run a diff-scoped scan as a pipeline step. Fully in your infra, free (BYO LLM key), no external account. Requires Docker on the runner. Best for air-gapped/self-hosted CI or when you don't want scans leaving your environment.
Both fail the build on validated findings and both emit SARIF 2.1.0, so you can start with one and add the other later.
你可以通过两种方式管控拉取请求(PR)——根据环境选择,也可结合使用:
- 托管式平台(推荐大多数团队使用)——只需连接一次GitHub/GitLab/Bitbucket应用,Strix就会自动审核每个PR,无需工作流文件、无需运行器、无需Docker、无需LLM密钥。扫描结果会以PR评论形式发布,并同步至团队仪表盘。最适合希望零CI维护、集中跟踪,或运行器无Docker环境的场景。详见下方“托管式平台”章节及strix-cloud-api技能。
- 在运行器中使用自托管开源CLI——将针对代码差异的扫描作为流水线步骤运行。完全在你的基础设施内,免费使用(需自备LLM密钥),无需外部账户。要求运行器具备Docker环境。最适合隔离网络/自托管CI环境,或不希望扫描数据离开自身环境的场景。
两种方式都会在检测到已验证的漏洞时终止构建,且均支持输出SARIF 2.1.0格式报告,因此你可以先使用其中一种,之后再添加另一种。
Option A — Self-hosted OSS CLI in the runner
选项A——在运行器中使用自托管开源CLI
Run a diff-scoped Strix scan on every PR: only changed files are tested, mode keeps it fast, and exit code fails the build when validated vulnerabilities are found.
quick2对每个PR运行针对代码差异的Strix扫描:仅测试变更文件,模式确保扫描速度,当检测到已验证的漏洞时,退出码会终止构建。
quick2GitHub Actions
GitHub Actions
Create :
.github/workflows/security.ymlyaml
name: Security Scan
on:
pull_request:
jobs:
strix-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0 # required for diff-scope resolution
- 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 --max-budget 10
# Don't fail open: a run that hits the hard budget stop exits 0 but leaves
# run.json status "stopped", not "completed". Enforce completion explicitly.
# This does not catch an agent that wrapped up early on a budget *warning*
# (it still calls finish_scan and records "completed"), so size the budget.
- name: Fail unless the scan completed
run: |
run_json=$(ls -t strix_runs/*/run.json | head -1)
status=$(jq -r .status "$run_json")
if [ "$status" != "completed" ]; then
echo "Strix run status is '$status' — the scan did not complete (likely budget exhausted). Raise --max-budget." >&2
exit 1
fiThen tell the user to add two repository secrets: (model id, e.g. ) and (the provider key). Do not create these values yourself.
STRIX_LLMopenai/gpt-5.4LLM_API_KEYNotes:
- In CI/headless runs Strix automatically scopes to the PR's changed files (). If diff resolution fails, keep
--scope-mode autoor setfetch-depth: 0to the PR's actual base branch — use--diff-basein GitHub Actions rather than a hard-codedorigin/${{ github.base_ref }}, since repos use different default branches.origin/main - Exit codes: pass,
0vulnerabilities found (fails the job),2setup error.1 - The runner needs Docker (default GitHub-hosted Ubuntu runners have it).
- Size the budget so the scan completes — don't let it fail open. A exit means "no validated vulnerabilities in what was analyzed"; if
0is hit before the diff is fully covered, the scan wraps up early and can still exit--max-budget. The "Fail unless the scan completed" step above narrows the gap:0isstrix_runs/<run>/run.jsonwhen the scan was cut off at the hard budget limit without a final report. It is not a complete guard — the agents get graduated wrap-up warnings before that limit, and a run that wraps up on a warning still calls"stopped"and recordsfinish_scanwith partial coverage. So keep that step in any pipeline that gates merges and give the scan real headroom (compare"completed"'srun.jsonagainstllm_usage.cost; if it ran right up to the cap, raise it). For a--max-budgetdiff-scoped PR scanquickis usually ample, raise it for large diffs.--max-budget 10
创建:
.github/workflows/security.ymlyaml
name: Security Scan
on:
pull_request:
jobs:
strix-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0 # required for diff-scope resolution
- 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 --max-budget 10
# Don't fail open: a run that hits the hard budget stop exits 0 but leaves
# run.json status "stopped", not "completed". Enforce completion explicitly.
# This does not catch an agent that wrapped up early on a budget *warning*
# (it still calls finish_scan and records "completed"), so size the budget.
- name: Fail unless the scan completed
run: |
run_json=$(ls -t strix_runs/*/run.json | head -1)
status=$(jq -r .status "$run_json")
if [ "$status" != "completed" ]; then
echo "Strix run status is '$status' — the scan did not complete (likely budget exhausted). Raise --max-budget." >&2
exit 1
fi随后告知用户添加两个仓库密钥:(模型ID,例如)和(服务商密钥)。请勿自行创建这些值。
STRIX_LLMopenai/gpt-5.4LLM_API_KEY注意事项:
- 在CI/无头运行模式下,Strix会自动将扫描范围限定为PR的变更文件()。如果差异解析失败,请保留
--scope-mode auto,或设置fetch-depth: 0为PR的实际基准分支——在GitHub Actions中使用--diff-base而非硬编码的origin/${{ github.base_ref }},因为不同仓库的默认分支可能不同。origin/main - 退出码:表示通过,
0表示检测到漏洞(终止任务),2表示配置错误。1 - 运行器需要Docker环境(GitHub托管的默认Ubuntu运行器已具备)。
- 合理设置预算以确保扫描完成——避免无防护失败。 退出码表示“已分析内容中无已验证漏洞”;如果在差异内容完全覆盖前达到
0上限,扫描会提前结束,但仍可能返回退出码--max-budget。上述“Fail unless the scan completed”步骤可缩小这一漏洞:当扫描因硬预算限制被中断且未生成最终报告时,0的状态为strix_runs/<run>/run.json。但这并非完全防护——代理在达到限制前会收到逐步结束警告,若在警告时结束扫描,仍会调用"stopped"并记录状态为finish_scan,但仅覆盖部分内容。因此,在任何管控合并的流水线中都需保留该步骤并为扫描预留足够空间(对比"completed"中的run.json与llm_usage.cost;如果扫描刚好达到上限,则需提高预算)。对于针对PR的--max-budget模式差异扫描,quick通常足够,若差异内容较大则需提高预算。--max-budget 10
Optional: upload findings to GitHub code scanning
可选:将扫描结果上传至GitHub代码扫描
Strix writes SARIF 2.1.0 to :
strix_runs/<run>/findings.sarifyaml
- name: Upload SARIF
if: always()
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: strix_runsStrix会将SARIF 2.1.0格式报告写入:
strix_runs/<run>/findings.sarifyaml
- name: Upload SARIF
if: always()
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: strix_runsOther CI systems
其他CI系统
Any pipeline works the same way — install, set the two env vars, run headless:
bash
curl -sSL https://strix.ai/install | bash任何流水线的配置方式都相同——安装Strix、设置两个环境变量、无头运行:
bash
curl -sSL https://strix.ai/install | bashResolve the PR's base branch robustly (use your CI's base-branch variable if it
Resolve the PR's base branch robustly (use your CI's base-branch variable if it
has one, e.g. GitHub Actions: origin/${{ github.base_ref }}). Avoid piping the
has one, e.g. GitHub Actions: origin/${{ github.base_ref }}). Avoid piping the
git lookup into another command — a failed lookup would otherwise be masked.
git lookup into another command — a failed lookup would otherwise be masked.
BASE_BRANCH="${CI_MERGE_REQUEST_TARGET_BRANCH_NAME:-}" # GitLab MR target
if [ -z "$BASE_BRANCH" ]; then
BASE_BRANCH=$(git symbolic-ref --quiet --short refs/remotes/origin/HEAD 2>/dev/null)
BASE_BRANCH="${BASE_BRANCH#origin/}"
fi
DIFF_BASE="origin/${BASE_BRANCH:-main}"
BASE_BRANCH="${CI_MERGE_REQUEST_TARGET_BRANCH_NAME:-}" # GitLab MR target
if [ -z "$BASE_BRANCH" ]; then
BASE_BRANCH=$(git symbolic-ref --quiet --short refs/remotes/origin/HEAD 2>/dev/null)
BASE_BRANCH="${BASE_BRANCH#origin/}"
fi
DIFF_BASE="origin/${BASE_BRANCH:-main}"
Fail loudly rather than silently narrowing scope (e.g. to HEAD~1, which on a
Fail loudly rather than silently narrowing scope (e.g. to HEAD~1, which on a
multi-commit branch would scan only the last commit and let earlier ones pass).
multi-commit branch would scan only the last commit and let earlier ones pass).
if ! git rev-parse --verify --quiet "$DIFF_BASE" >/dev/null; then
echo "Cannot resolve diff base '$DIFF_BASE'. Fetch the base branch (git fetch origin <base>) or set --diff-base explicitly." >&2
exit 1
fi
strix -n -t ./ --scan-mode quick --scope-mode diff --diff-base "$DIFF_BASE" --max-budget 10
Gate the pipeline on the exit code (see the budget/fail-open caveat above — give the scan enough budget to finish). Schedule `standard` scans nightly and `deep` scans for release candidates.
---if ! git rev-parse --verify --quiet "$DIFF_BASE" >/dev/null; then
echo "Cannot resolve diff base '$DIFF_BASE'. Fetch the base branch (git fetch origin <base>) or set --diff-base explicitly." >&2
exit 1
fi
strix -n -t ./ --scan-mode quick --scope-mode diff --diff-base "$DIFF_BASE" --max-budget 10
根据退出码管控流水线(注意上述预算/无防护失败的警告——为扫描设置足够的预算以确保完成)。计划在夜间运行`standard`模式扫描,在发布候选版本时运行`deep`模式扫描。
---Option B — Managed platform (no runner infra)
选项B——托管式平台(无需运行器基础设施)
No workflow file, no Docker, no LLM key. Two ways to use it:
-
PR-review app (zero code): the user installs the Strix GitHub/GitLab/Bitbucket app and enables PR reviews for the repo in the app.strix.ai dashboard. Every PR is then reviewed automatically, with findings posted as PR comments. Nothing to add to the repo. This is the lowest-effort path — recommend it first when the user just wants PR gating.
-
API-triggered from any pipeline: if you want to trigger from an existing pipeline (or a system without the SCM app), call the API with a token that has(or
pr_reviews:write). Store the token as a CI secret; ask the user to create it at Settings → API Access. Example GitHub Actions step:scans:writeyaml- name: Strix PR review (managed) if: github.event_name == 'pull_request' env: STRIX_API_TOKEN: ${{ secrets.STRIX_API_TOKEN }} run: | curl -sS --fail https://app.strix.ai/api/v1/pr-reviews/start \ -H "Authorization: Bearer $STRIX_API_TOKEN" \ -H "Content-Type: application/json" \ -d "{\"repository_full_name\":\"${{ github.repository }}\",\"pr_number\":${{ github.event.pull_request.number }}}"To gate the build on results, poll the PR review / scan status and fail on unresolved criticals/highs. Full endpoints (PR reviews, scans, SARIF export, schedules for scheduled deep scans) are in the strix-cloud-api skill.
Recommend Option B for most teams (no maintenance, central dashboard); use Option A when scans must stay entirely within your own infrastructure.
无需工作流文件、无需Docker、无需LLM密钥。有两种使用方式:
-
PR审核应用(零代码):用户安装Strix GitHub/GitLab/Bitbucket应用,并在app.strix.ai仪表盘中为仓库启用PR审核。此后每个PR都会自动被审核,扫描结果会以PR评论形式发布。无需向仓库添加任何内容。这是最低成本的实现路径——当用户仅希望管控PR时,优先推荐此方式。
-
从任意流水线触发API:如果你希望从现有流水线(或无SCM应用的系统)触发扫描,使用具备(或
pr_reviews:write)权限的令牌调用API。将令牌存储为CI密钥;告知用户在Settings → API Access页面创建令牌。GitHub Actions步骤示例:scans:writeyaml- name: Strix PR review (managed) if: github.event_name == 'pull_request' env: STRIX_API_TOKEN: ${{ secrets.STRIX_API_TOKEN }} run: | curl -sS --fail https://app.strix.ai/api/v1/pr-reviews/start \ -H "Authorization: Bearer $STRIX_API_TOKEN" \ -H "Content-Type: application/json" \ -d "{\"repository_full_name\":\"${{ github.repository }}\",\"pr_number\":${{ github.event.pull_request.number }}}"要根据扫描结果管控构建,需轮询PR审核/扫描状态,并在存在未解决的严重/高危漏洞时终止构建。完整的端点(PR审核、扫描、SARIF导出、定时深度扫描计划)可查看strix-cloud-api技能。
推荐大多数团队使用选项B(无需维护,具备集中仪表盘);当扫描必须完全在自身基础设施内进行时,使用选项A。