ci-security-scanning-with-strix — an agent skill by usestrix

Add security scanning to CI/CD with Strix — GitHub Actions, GitLab CI, or any pipeline — so every pull request gets a diff-scoped AI pentest that blocks vulnerable code before it merges, with results as PR comments and SARIF uploaded to code scanning. Covers both the self-hosted open-source CLI (run

Set up Strix in CI/CD 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 managed pentesting with strix 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 do not 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. Option A — Self hosted OSS CLI in the runner Run a diff scoped Strix scan on every PR: only changed files are tested, quick mode keeps it fast, and exit code 2 fails the build when validated vulnerabilities are found. GitHub Actions Create .github/workflows/security.yml : Then tell the user to add two repository secrets: STRIX LLM (model id, for example openai/gpt 5.4 ) and LLM API KEY (the provider key). Do not create these values yourself. Notes: In CI/headless runs Strix automatically scopes to the PR's changed files ( scope mode auto ). If diff resolution fails, keep fetch depth: 0 or set diff base to the PR's actual base branch — use origin/${{ github.base ref }} in GitHub Actions rather than a hard coded origin/main , since repos use different default branches. Exit codes: 0 pass, 2 vulnerabilities found (fails the job), 1 setup error. The runner needs Docker (default GitHub hosted Ubuntu runners have it). Size the budget so the scan completes — do not let it fail open. A 0 exit means "no validated vulnerabilities in what was analyzed"; if max budget is hit before the diff is fully covered, the scan wraps up early and can still exit 0 . The "Fail unless the scan completed" step above narrows the gap: strix runs/<run /run.json is "stopped" when 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 finish scan and records "completed" with partial coverage. So keep that step in any pipeline that gates merges and give the scan real headroom (compare run.json 's llm usage.cost against max budget ; if it ran right up to the cap, raise it). For a quick diff scoped PR scan max budget 10 is usually ample, raise it for large diffs. Optional: upload findings to GitHub code scanning Strix writes SARIF 2.1.0 to strix runs/<run /findings.sarif : Other CI systems Any pipeline works the same way — install, set the two env vars, run headless: 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. Option B — Managed platform (no runner infra) No workflow file, no Docker, no LLM key. Three ways to use it: 1. 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. 2. CLI triggered from any pipeline: if you want to trigger from an existing pipeline (or a system without the SCM app), use the same strix binary with a token that has pr reviews:write . Store the token as a CI secret and ask the user to create it at Settings → API Access . Read the repository's provider and installation id once with strix cloud repos list . Example GitHub Actions step: Output is JSON when stdout is not a terminal, and there are no prompts without a TTY. To gate the build on results, poll strix cloud pr reviews get <id json and fail on unresolved criticals or highs. The raw REST endpoint ( POST /api/v1/pr reviews/start ) works too when the pipeline cannot install the CLI. 3. Source upload from a pipeline without an SCM app: upload the checked out tree as a cloud code review ( scans:write and uploads:write ). The two step digest handoff keeps a human in control of what leaves the runner: Exit codes: 0 success, 4 auth or plan limit, 5 payment required. Non Enterprise scans consume credits. Full CLI coverage (PR reviews, scans, SARIF export, schedules) is in the managed pentesting with strix skill. Recommend Option B for most teams (no maintenance, central dashboard); use Option A when scans must stay entirely within your own infrastructure.