---
id: gh-fix-security-vulnerabilities-with-strix
name: "fix-security-vulnerabilities-with-strix"
url: https://skills.yangsir.net/skill/gh-fix-security-vulnerabilities-with-strix
author: usestrix
domain: security
tags: ["security", "vulnerability", "pentest", "code-fixing", "remediation"]
install_count: 8300
rating: 4.50 (120 reviews)
github: https://github.com/usestrix/strix/tree/main/skills/fix-security-vulnerabilities-with-strix
---

# fix-security-vulnerabilities-with-strix

> 此技能用于修复安全扫描发现的漏洞。它能按严重性对漏洞进行排序，指导开发者从根因修复而非仅修补表面症状，并通过重新扫描验证每个修复是否真正关闭了漏洞。适用于注入、XSS、SSRF、越权、IDOR 等常见安全问题，显著缩短安全修复周期，提升修复质量。

**Stats**: 8,300 installs · 4.5/5 (120 reviews)

## Before / After 对比

### 漏洞修复效率提升

**Before**:

开发者收到安全扫描报告后，需要手动阅读每个漏洞的详细描述，判断严重性，查找相关代码位置，并自行设计修复方案。整个过程耗时数小时，且容易忽略关键漏洞或仅修复特定攻击负载，导致修复不彻底，漏洞反复出现。

**After**:

此技能自动对漏洞进行严重性排序，提供根因修复建议和具体代码位置，开发者只需按指导修改，然后重新扫描验证。一个漏洞的修复时间从数小时缩短到几十分钟，修复更彻底，漏洞复测通过率高。

| Metric | Before | After | Change |
|---|---|---|---|
| 平均单漏洞修复时长 | 120分钟 | 20分钟 | -83% |

## Readme

# 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 (e.g. parameterize all queries, don't blocklist one string; enforce authorization in the handler, don't hide 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 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.


---
*Source: https://skills.yangsir.net/skill/gh-fix-security-vulnerabilities-with-strix*
*Markdown mirror: https://skills.yangsir.net/api/skill/gh-fix-security-vulnerabilities-with-strix/markdown*