# Ci Security Scanning With Strix

> Añade escaneo de seguridad al CI/CD con Strix: cada PR recibe un pentest con IA acotado al diff que bloquea código vulnerable antes de mergear.

Fuente: https://skillsagentes.com/skills/usestrix/strix/ci-security-scanning-with-strix
Markdown: https://skillsagentes.com/skills/usestrix/strix/ci-security-scanning-with-strix.md

Repositorio: https://github.com/usestrix/strix
Autor: usestrix
Licencia: Apache-2.0
Actualizado: hace 5 días
Coste de contexto: 145 tok instalada, 2k tok al activarse, 2k tok con todos los archivos del bundle
Bundle: 1 archivo, 8 KB
Permisos que pide: ninguno declarado

## Instalación

Un skill son archivos markdown: los mismos archivos valen para cualquier agente y lo único que cambia es el directorio de destino, es decir la bandera `--agent`. Añade `-g` para instalarlo en todos los proyectos de la máquina.

```bash
# Claude Code
npx -y skills add usestrix/strix --skill ci-security-scanning-with-strix --agent claude-code
# Cursor
npx -y skills add usestrix/strix --skill ci-security-scanning-with-strix --agent cursor
# Codex
npx -y skills add usestrix/strix --skill ci-security-scanning-with-strix --agent codex
# Gemini CLI
npx -y skills add usestrix/strix --skill ci-security-scanning-with-strix --agent gemini
# Windsurf
npx -y skills add usestrix/strix --skill ci-security-scanning-with-strix --agent windsurf
# Cline
npx -y skills add usestrix/strix --skill ci-security-scanning-with-strix --agent cline
```

## Qué hace

- Ejecuta un escaneo Strix acotado al diff en cada PR, con el CLI open-source auto-hospedado o la plataforma gestionada app.strix.ai
- Falla el build con código de salida 2 cuando hay vulnerabilidades validadas
- Sube los hallazgos como SARIF 2.1.0 a GitHub code scanning
- Con la plataforma gestionada, publica resultados como comentarios de PR sin workflow, runner ni clave LLM

## Cuándo usarla

- Quieres añadir escaneo de seguridad, SAST/DAST, pentesting o revisión automatizada al pipeline de CI o al gate de pre-merge

## Qué la activa

- "Añade un escaneo de seguridad de Strix a mi pipeline de GitHub Actions"
- "Configura Strix para bloquear PRs con vulnerabilidades"

## Antes de instalar

- El CLI auto-hospedado necesita Docker en el runner y las variables STRIX_LLM y LLM_API_KEY.
- Necesita en el PATH: curl, git, jq
- Variables de entorno: BASE_BRANCH, CI_MERGE_REQUEST_TARGET_BRANCH_NAME, DIFF_BASE, STRIX_API_TOKEN
- makes network requests
- needs API credentials

## Archivos

- SKILL.md — 8 KB

## SKILL.md

Reproducido tal cual desde usestrix/strix bajo Apache-2.0. Esta sección es el documento original y está en inglés.

# 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`:

```yaml
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
```

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`:

```yaml
      - name: Upload SARIF
        if: always()
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: strix_runs
```

## Other CI systems

Any pipeline works the same way — install, set the two env vars, run headless:

```bash
curl -sSL https://strix.ai/install | bash
# Resolve the PR's base branch robustly (use your CI's base-branch variable if it
# has one, for example GitHub Actions: origin/${{ github.base_ref }}). Avoid piping the
# 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}"
# Fail loudly rather than silently narrowing scope (for example, to HEAD~1, which on a
# 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.

---

# Option B — Managed platform (no runner infra)

No workflow file, no Docker, no LLM key. Two 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. **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 `pr_reviews:write` (or `scans:write`). Store the token as a CI secret; ask the user to create it at **Settings → API Access**. Example GitHub Actions step:

   ```yaml
   - 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 **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.

## Dónde encaja

- Categoría: [Seguridad](https://skillsagentes.com/categorias/seguridad.md) — Auditorías, revisión de dependencias, manejo de secretos y modelado de amenazas.
- Creador: [usestrix](https://skillsagentes.com/creators/usestrix.md) — 9 skills en el directorio
- [Todas las skills](https://skillsagentes.com/skills.md)
- [Ranking de instalaciones](https://skillsagentes.com/ranking.md)

## Otras skills del mismo repositorio

- [Api Security Testing](https://skillsagentes.com/skills/usestrix/strix/api-security-testing.md): Pon a prueba una API REST, GraphQL o gRPC con Strix: agentes autónomos enumeran endpoints y explotan el OWASP API Security Top 10 (2023) con una PoC funcional por cada hallazgo.
- [Owasp Top 10 Testing](https://skillsagentes.com/skills/usestrix/strix/owasp-top-10-testing.md): Prueba una aplicación contra el OWASP Top 10:2025 con Strix: agentes de IA que intentan exploits reales y reportan solo lo probado, con PoC.
- [Penetration Testing With Strix](https://skillsagentes.com/skills/usestrix/strix/penetration-testing-with-strix.md): Pentestea una app web, API, código, repo, URL, dominio o IP con Strix: agentes autónomos que explotan y demuestran vulnerabilidades con PoC, por CLI autoalojada o nube gestionada app.strix.ai.
- [Find Security Vulnerabilities In Code](https://skillsagentes.com/skills/usestrix/strix/find-security-vulnerabilities-in-code.md): Revisión de seguridad de caja blanca con IA: lee el código fuente, razona sobre el flujo de datos y la autorización, y explota lo que encuentra con PoC.
- [Web App Penetration Testing](https://skillsagentes.com/skills/usestrix/strix/web-app-penetration-testing.md): Pentestea una app web o sitio de extremo a extremo: testeo de caja negra que encuentra y explota vulnerabilidades reales (auth bypass, IDOR, inyección, XSS, SSRF, lógica de negocio) con Strix.

---

Skills Agentes · [Índice de páginas en markdown](https://skillsagentes.com/sitemap.md) · [Inicio](https://skillsagentes.com/index.md)