fix-security-vulnerabilities-with-strix

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Fix Strix findings and verify

修复Strix检测结果并验证

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

将经过验证的Strix检测结果转化为简洁、正确的修复方案——并通过重新扫描验证修复效果。

1. Triage

1. 分级处置

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.

从扫描运行的位置获取检测结果：

开源CLI —— 结果文件位于
```
strix_runs/<运行名称>/
```
目录下：
- ```
vulnerabilities/*.md
```
  —— 每个文件对应一项检测结果：包含描述、严重程度、PoC步骤或脚本、受影响代码位置、修复指导。
- ```
vulnerabilities.json
```
  —— 以JSON格式存储的相同检测结果（包含ID、严重程度、CWE/CVE、带有
```
fix_before
```
  /
```
fix_after
```
  修复建议的
```
code_locations
```
  ，若有提供）。
云端服务（app.strix.ai） —— 通过
```
GET /api/v1/scans/{scanId}
```
（或组织范围的
```
GET /api/v1/vulnerabilities
```
）接口获取扫描的
```
vulnerabilities[]
```
数据。每项数据包含
```
severity, cwe, endpoint, method, impact, technical_analysis, poc_description, poc_script_code
```
，对于代码检测结果，还包含
```
code_file
```
/
```
code_diff
```
/
```
code_before
```
/
```
code_after
```
。身份验证方式请参考managed-pentesting-with-strix技能文档。

按严重程度排序处理优先级：严重→高危→中危→低危。所有Strix检测结果均已通过可运行的PoC验证，因此请勿在未自行测试PoC的情况下将检测结果标记为误报。

2. Fix

2. 修复漏洞

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).

针对每项检测结果：

尽可能使用检测结果文件中的PoC复现漏洞。
修复问题根源，而非仅针对特定攻击载荷（例如：对所有查询使用参数化，而非仅拦截单个字符串；在处理程序中强制实施授权，而非隐藏端点）。
优先使用框架内置的防护机制（ORM参数化、模板自动转义、CSRF中间件、集中式授权），而非临时的 sanitization（数据清理）方案。
保持代码变更最小化，并遵循仓库现有的代码模式。检测结果文件通常包含
```
fix_before
```
/
```
fix_after
```
代码片段——可将其作为起点，但不要直接照搬。

常见漏洞类型及预期修复方案：注入攻击→在数据输出点使用参数化/转义；IDOR/访问控制失效→添加对象级授权检查；SSRF→使用允许列表+阻止内部IP范围；XSS→基于上下文的输出编码+CSP；密钥泄露→轮换密钥并从代码/历史记录中移除；认证问题→修复服务器端检查（绝不要仅在客户端处理）。

3. Verify by re-running Strix

3. 通过重新运行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

undefined

修复完成后，针对修复区域重新扫描，确认漏洞已消除。在原扫描环境（或两个环境都）中进行验证：

开源CLI：

bash

undefined

Re-test just the changed files (fast). Resolve the repo's real default

仅测试变更的文件（速度快）。解析仓库实际的默认分支，而非假设为origin/main（许多仓库使用master/develop）。

branch instead of assuming origin/main (many repos use master/develop).

避免将当前分支的上游作为基准——它与HEAD的合并基准就是HEAD，会产生空差异，导致错误的“无漏洞”结果。

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.

origin/HEAD可能是悬空的符号引用——仅当目标存在时才保留。

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

不使用静默回退：像HEAD~1这样的猜测仅能覆盖多提交修复分支的最后一次提交。如果无法解析基准分支，请询问用户基准分支（或使用下面的聚焦式--instruction验证，无需差异基准）。

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

[ -n "$DIFF_BASE" ] || { echo "将DIFF_BASE设置为你的修复分支将合并到的分支。" >&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)

strix -n -t ./ --instruction "Verify the SQL injection in app/api/search.py is fixed. Original PoC: <poc>" --max-budget 5

退出码说明：`2` = 仍存在漏洞（查看新的`strix_runs/<运行名称>/vulnerabilities/`文件并迭代修复）；`0` = 分析范围内无漏洞**。在信任`0`结果之前，确认扫描未提前终止——检查`run.json`中的状态是否为已完成，并对比`llm_usage.cost`与`--max-budget`：预算耗尽会导致`status: "stopped"`，而因预算警告结束的扫描会记录`"completed"`但覆盖范围不完整。为验证分配足够的预算，优先重新运行特定PoC作为最可靠的验证信号。

**云端服务：** 使用相同配置重新扫描并轮询结果，确认漏洞不再出现：
```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[]

轮询GET /scans/$new_id直到扫描完成，然后检查其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.

或者，如果云端扫描来自仓库/PR，在修复分支上触发新的PR审核（`POST /pr-reviews/start`）。平台还支持直接重新测试单个漏洞：`POST /api/v1/vulnerabilities/{vulnerabilityId}/retest`。

- 当PoC是简单请求/脚本时，也可手动重新运行——这是最快的验证方式。
- 运行项目自身的测试套件，确保修复不会破坏现有功能。

4. Report

4. 报告

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.

按每项检测结果总结：严重程度、问题根源、应用的修复（文件:行号）、验证结果（重新扫描无漏洞 / PoC无法再复现）。报告中切勿包含有效密钥；若存在密钥泄露，请说明需要轮换密钥。