fix-security-vulnerabilities-with-strix

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) — pull findings with the CLI: strix cloud vulns list --scan-id <scan-id> --json (or strix cloud scans get <scan-id> --json | jq '.vulnerabilities', or strix cloud vulns list --severity critical org-wide). Each finding 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. After a fix is verified, mark it with strix cloud vulns update <id> --status fixed. See the managed-pentesting-with-strix skill for strix cloud login and scopes.

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:

# 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

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:

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.