# Fix Security Vulnerabilities With Strix

> Corrige vulnerabilidades encontradas por un pentest de Strix: clasifica por severidad, parchea la causa raíz y vuelve a escanear para probar el fix.

Fuente: https://skillsagentes.com/skills/usestrix/strix/fix-security-vulnerabilities-with-strix
Markdown: https://skillsagentes.com/skills/usestrix/strix/fix-security-vulnerabilities-with-strix.md

Repositorio: https://github.com/usestrix/strix
Autor: usestrix
Licencia: Apache-2.0
Actualizado: hace 5 días
Coste de contexto: 126 tok instalada, 1.4k tok al activarse, 1.4k tok con todos los archivos del bundle
Bundle: 1 archivo, 6 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 fix-security-vulnerabilities-with-strix --agent claude-code
# Cursor
npx -y skills add usestrix/strix --skill fix-security-vulnerabilities-with-strix --agent cursor
# Codex
npx -y skills add usestrix/strix --skill fix-security-vulnerabilities-with-strix --agent codex
# Gemini CLI
npx -y skills add usestrix/strix --skill fix-security-vulnerabilities-with-strix --agent gemini
# Windsurf
npx -y skills add usestrix/strix --skill fix-security-vulnerabilities-with-strix --agent windsurf
# Cline
npx -y skills add usestrix/strix --skill fix-security-vulnerabilities-with-strix --agent cline
```

## Qué hace

- Clasifica los hallazgos de Strix por severidad (critical → high → medium → low) desde artefactos locales o la API cloud
- Corrige la causa raíz de cada hallazgo (parametrización, autorización por objeto, allowlist, escapado) en vez de bloquear un payload
- Reejecuta Strix acotado a los archivos corregidos para verificar que el hallazgo desapareció
- Resume por hallazgo: severidad, causa raíz, corrección aplicada y resultado de la verificación

## Cuándo usarla

- Después de un escaneo de Strix que reportó hallazgos
- El usuario pide remediar o parchear problemas de un reporte strix_runs, vulnerabilities.json, findings.sarif o un scan en la nube

## Qué la activa

- "Corrige las vulnerabilidades que encontró Strix y verifica el fix"
- "Arregla el hallazgo de IDOR y vuelve a escanear para confirmar"

## Antes de instalar

- Necesita en el PATH: curl, git, jq
- Variables de entorno: BASE, DIFF_BASE
- reads environment config

## Archivos

- SKILL.md — 6 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.

# Fix Strix findings and verify

Turn validated Strix findings into minimal, correct fixes — and prove they work by re-scanning.

## 1. Triage

Get the findings from wherever the scan ran:

- **OSS CLI** — artifacts in `strix_runs/<run-name>/`:
  - `vulnerabilities/*.md` — one finding per file: description, severity, PoC steps or script, affected code locations, remediation guidance.
  - `vulnerabilities.json` — the same findings as JSON (ids, severity, CWE/CVE, `code_locations` with `fix_before`/`fix_after` suggestions when available).
- **Cloud (app.strix.ai)** — fetch the scan's `vulnerabilities[]` via `GET /api/v1/scans/{scanId}` (or `GET /api/v1/vulnerabilities` org-wide). Each carries `severity, cwe, endpoint, method, impact, technical_analysis, poc_description, poc_script_code` and, for code findings, `code_file`/`code_diff`/`code_before`/`code_after`. See the **managed-pentesting-with-strix** skill for auth.

Order work by severity: critical → high → medium → low. Every Strix finding was validated with a working proof-of-concept, so do not dismiss findings as false positives without re-testing the PoC yourself.

## 2. Fix

For each finding:

1. Reproduce it with the PoC from the finding file when feasible.
2. Fix the root cause, not the specific payload (parameterize every query instead of blocking one string, and enforce authorization in the handler instead of hiding the endpoint).
3. Prefer the framework's built-in defense (ORM parameterization, template auto-escaping, CSRF middleware, centralized authz) over ad-hoc sanitization.
4. Keep the diff minimal and apply the repo's existing patterns. Finding files often include `fix_before`/`fix_after` snippets — use them as a starting point, not verbatim.

Common finding classes and expected fixes: injection → parameterization/escaping at the sink; IDOR/broken access control → object-level authorization checks; SSRF → allowlist + block internal ranges; XSS → context-aware output encoding + CSP; secrets exposure → rotate the secret AND remove it from code/history; auth issues → fix the server-side check (never client-side).

## 3. Verify by re-running Strix

After fixing, re-scan scoped to the fixed area and confirm the finding is gone. Verify in whichever environment you scanned (or both):

**OSS CLI:**
```bash
# Re-test just the changed files (fast). Resolve the repo's real default
# branch instead of assuming origin/main (many repos use master/develop).
# Avoid the current branch's own upstream as the base — its merge base with
# HEAD would be HEAD, giving an empty diff and a falsely clean result.
DIFF_BASE=$(git symbolic-ref --quiet --short refs/remotes/origin/HEAD 2>/dev/null)
# origin/HEAD can be a dangling symbolic ref — keep it only if its target exists.
git rev-parse --verify --quiet "$DIFF_BASE" >/dev/null 2>&1 || DIFF_BASE=""
if [ -z "$DIFF_BASE" ]; then
  for b in origin/main origin/master origin/develop; do
    git rev-parse --verify --quiet "$b" >/dev/null && DIFF_BASE="$b" && break
  done
fi
# No silent fallback: a guess like HEAD~1 would cover only the last commit of a
# multi-commit fix branch. If no base resolves, ask the user for the base branch
# (or use the focused --instruction verification below, which needs no diff base).
[ -n "$DIFF_BASE" ] || { echo "Set DIFF_BASE to the branch your fix will merge into." >&2; exit 1; }
strix -n -t ./ --scan-mode quick --scope-mode diff --diff-base "$DIFF_BASE" --max-budget 5

# Or re-test with the original finding as focus (no diff base needed)
strix -n -t ./ --instruction "Verify the SQL injection in app/api/search.py is fixed. Original PoC: <poc>" --max-budget 5
```
Exit codes: `2` = findings remain (read the new `strix_runs/<run>/vulnerabilities/` and iterate); `0` = clean **for what was analyzed**. Before trusting a `0`, confirm the run wasn't cut short — check `run.json` for a completed status and compare its `llm_usage.cost` with `--max-budget`: a hard budget stop leaves `status: "stopped"`, but a run that wrapped up on a budget warning records `"completed"` with partial coverage. Give verification enough budget to finish, and prefer re-running the specific PoC as the ground-truth signal.

**Cloud:** rerun with the same config and re-poll, then confirm the finding no longer appears:
```bash
new_id=$(curl -sS "$BASE/scans/$scan_id/rerun" "${auth[@]}" -X POST | jq -r .scan_id)
# poll GET /scans/$new_id until completed, then check its vulnerabilities[]
```
Or, if the cloud scan came from a repo/PR, trigger a fresh PR review on the fix branch (`POST /pr-reviews/start`). The platform also retests a single finding directly: `POST /api/v1/vulnerabilities/{vulnerabilityId}/retest`.

- Also re-run the PoC manually when it is a simple request/script — fastest signal.
- Run the project's own test suite to make sure the fix does not break behavior.

## 4. Report

Summarize per finding: severity, root cause, fix applied (file:line), verification result (re-scan clean / PoC no longer reproduces). Never include live secrets in the report; if a secret leaked, state that rotation is required.

## 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.
- [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.
- [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.
- [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.
- [Ci Security Scanning With Strix](https://skillsagentes.com/skills/usestrix/strix/ci-security-scanning-with-strix.md): 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.

---

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