fix-security-vulnerabilities-with-strix

Original：🇺🇸 English

Translated

Fix security vulnerabilities found by a Strix pentest (open-source CLI or app.strix.ai cloud) — triage by severity, patch the root cause rather than the symptom, and re-run Strix to prove each fix actually closes the exploit. Handles injection, XSS, SSRF, broken access control, IDOR, and other validated findings. Use after a Strix scan reports findings, or when the user asks to remediate, patch, or fix security issues from a strix_runs report, vulnerabilities.json, findings.sarif, or a cloud scan.

6installs

Sourceusestrix/strix

Added on2026-08-08

NPX Install

npx skill4agent add usestrix/strix fix-security-vulnerabilities-with-strix

SKILL.md Content

View Translation Comparison →

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:

Reproduce it with the PoC from the finding file when feasible.
Fix the root cause, not the specific payload (e.g. parameterize all queries, don't blocklist one string; enforce authorization in the handler, don't hide the endpoint).
Prefer the framework's built-in defense (ORM parameterization, template auto-escaping, CSRF middleware, centralized authz) over ad-hoc sanitization.
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:

= findings remain (read the new

strix_runs/<run>/vulnerabilities/

and iterate);

= clean for what was analyzed. Before trusting a

, 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 doesn't 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.