Guide · Agent skill

CI/CD Security Scanning with Strix: setup and tutorial

Updated 2026-10-29 · written with AI from the project's own documentation and checked against our catalogue data

This guide explains the CI/CD Security Scanning with Strix agent skill, which teaches an AI agent to add Strix security scanning to a pipeline so that pull requests are checked for vulnerabilities before they merge. It is written for developers and engineers who maintain GitHub Actions or GitLab CI and have not used agent skills before. By the end you will know how to install the skill, ask for the setup in plain language, and choose between the self-hosted CLI and the managed app.strix.ai platform.

CI/CD Security Scanning with Strixusestrix/strix · Apache-2.0 Download the skill

Quick start

1Install the skill. Download the ZIP from this page and unzip it into ~/.claude/skills/ or a project's .claude/skills/ folder, or upload it under Settings → Capabilities → Skills in the Claude apps.
2Choose your path. Pick the managed platform for zero CI maintenance, or the self-hosted CLI if your runners have Docker and you want scans to stay in your infrastructure.
3Ask the agent for the setup. Describe your pipeline in plain language, for example GitHub Actions on pull requests, and ask for a security scanning step.
4Add the secrets. For the self-hosted path, store STRIX_LLM and LLM_API_KEY as CI secrets. The agent should not create these values for you.
5Review and merge the workflow. Check the generated workflow, including the budget and completion check, then commit it and open a test pull request.
6Confirm results. Look for the scan outcome in the job's exit status and PR comments, and check the SARIF upload if you enabled it.

What does the skill make the agent do?

The skill lets your agent set up Strix, an open-source AI security testing tool, inside your CI/CD pipeline. Strix runs a diff-scoped scan on each pull request, so only the changed files are tested. Findings can be posted as PR comments, and results can be uploaded to GitHub code scanning as SARIF 2.1.0.

The skill covers two paths. The self-hosted open-source CLI runs inside your own CI runner. The managed platform at app.strix.ai uses a GitHub, GitLab or Bitbucket app and needs no runner infrastructure.

Writes a GitHub Actions workflow or a pipeline step for any CI system
Runs a quick, diff-scoped scan on pull requests
Fails the build when validated vulnerabilities are found (exit code 2)
Optionally uploads SARIF results to GitHub code scanning

How do you install the skill?

Download the skill ZIP from this page and unzip it. Put the resulting skill folder in ~/.claude/skills/ to make it available across your projects, or in a project's .claude/skills/ folder to limit it to that repository.

In the Claude apps you can instead upload the ZIP under Settings → Capabilities → Skills.

Personal install: unzip into ~/.claude/skills/
Project install: unzip into the project's .claude/skills/ folder
Claude apps: Settings → Capabilities → Skills, then upload the ZIP

What do you need before you start?

The requirements depend on the path you choose. The self-hosted path needs Docker on the CI runner, the Strix CLI (installed with curl from strix.ai), and an LLM provider API key stored as a CI secret. The managed path needs a GitHub, GitLab or Bitbucket app connection and an app.strix.ai account.

The skill runs scripts and uses the network, so review the commands it writes before you commit them to your pipeline.

Self-hosted: Docker on the runner, Strix CLI, LLM API key as a CI secret
Managed: GitHub, GitLab or Bitbucket app, and an app.strix.ai account

How do you set up the self-hosted scan in GitHub Actions?

Ask the agent to create .github/workflows/security.yml. The workflow below checks out the repository with full history, installs Strix, runs a quick scan, and fails the job unless the run status is completed. Add two repository secrets named STRIX_LLM (a model id, for example openrouter/z-ai/glm-5.3) and LLM_API_KEY (your provider key).

The fetch-depth setting is required so the diff can be resolved. The final step guards against a scan that hit its budget limit and stopped early.

Exit 0 means pass, exit 2 means validated vulnerabilities were found, exit 1 means a setup error
Adding --fail-on high fails only on high and critical findings, but lower findings are still reported

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 --max-budget 10

      - 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

How do you use other CI systems or upload SARIF results?

For any other pipeline, install Strix, set the two environment variables, and run the CLI headless. The base branch must resolve correctly so the diff is right. Use your CI's base-branch variable where one exists, such as CI_MERGE_REQUEST_TARGET_BRANCH_NAME in GitLab. The script fails loudly rather than silently narrowing scope.

To send findings to GitHub code scanning, add an upload step after the scan. Strix writes SARIF 2.1.0 to strix_runs/<run>/findings.sarif.

Use origin/${{ github.base_ref }} in GitHub Actions rather than a hard-coded origin/main
Schedule standard scans nightly and deep scans for release candidates

curl -sSL https://strix.ai/install | bash
BASE_BRANCH="${CI_MERGE_REQUEST_TARGET_BRANCH_NAME:-}"
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}"
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

How do you use the managed platform instead?

The simplest managed option is the PR-review app. Install the Strix GitHub, GitLab or Bitbucket app and enable PR reviews for the repository in the app.strix.ai dashboard. Every PR is then reviewed automatically, with findings posted as PR comments, and nothing needs to be added to the repository.

If you want to trigger reviews from an existing pipeline, create a token with pr_reviews:write at Settings → API Access, store it as a CI secret, and use the strix cloud pr-reviews start command. The source excerpt for this skill stops partway through its gating instructions, so read the full SKILL.md before you rely on managed results to block merges.

Managed app: no workflow file, no Docker, no LLM key
Pipeline trigger: token with pr_reviews:write, stored as a CI secret

What are the safety and accuracy limits?

A passing scan does not mean the code is secure. It means no validated vulnerabilities were found in what was analyzed. A scan that runs out of budget can finish early, so give quick PR scans enough headroom and keep the completion check in any pipeline that gates merges.

If you choose the managed platform, your data is sent to an external service. Use the self-hosted path when scan results or code must stay inside your environment.

Compare run.json llm_usage.cost against --max-budget and raise the budget if a scan runs right up to the cap
Self-hosted scans use your own LLM key, so model costs are yours to manage

What people use it for

Blocking pull requests that introduce validated vulnerabilities before they merge
Adding a security step to an existing GitHub Actions or GitLab CI pipeline
Running nightly standard scans and deeper scans before a release
Getting PR comments without maintaining runners, using the managed app.strix.ai path
Uploading findings to GitHub code scanning for central tracking

Frequently asked questions

How do I install the CI/CD Security Scanning with Strix skill?

Download the skill ZIP from this page and unzip it into ~/.claude/skills/ for personal use or a project's .claude/skills/ folder for one repository. In the Claude apps, you can upload the ZIP under Settings → Capabilities → Skills instead.

What does the Strix CI scan require?

The self-hosted path needs Docker on the CI runner, the Strix CLI installed with curl from strix.ai, and an LLM provider API key stored as a CI secret. The managed path needs a GitHub, GitLab or Bitbucket app and an app.strix.ai account, with no Docker or LLM key on your side.

Is Strix free and what is its licence?

Strix is licensed under Apache-2.0. The self-hosted CLI runs in your runner and uses your own LLM key, so you pay your model provider for usage. The source does not list managed-platform pricing, so check app.strix.ai for that.

Can I use this with GitLab CI or Bitbucket instead of GitHub Actions?

Yes. The skill includes a generic shell approach for any pipeline and uses GitLab's CI_MERGE_REQUEST_TARGET_BRANCH_NAME variable to find the base branch. The managed app also supports GitLab and Bitbucket.

Why did my Strix job fail with exit code 1 or a diff base error?

Exit code 1 means a setup error. A common cause is that the base branch cannot be resolved, so keep fetch-depth set to 0 in GitHub Actions, or fetch the base branch with git fetch origin <base> or set --diff-base explicitly.

Does a passing Strix scan mean my code is secure?

No. A pass means no validated vulnerabilities were found in what was analyzed. A budget-limited run can finish early, and --fail-on high ignores lower-severity findings, so review the reported results rather than relying on the pass alone.

New agent skills, repos and AI tools — every week

The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.

Our verdict

Use this skill if you maintain GitHub Actions or GitLab CI and want a diff-scoped security step on pull requests, either self-hosted with Docker on your runners or through the managed app. Pick another approach if your runners cannot run Docker, you have no LLM key for the self-hosted path, or your code must never leave your environment, since the managed platform sends data to an external service.

Download the skill