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 strix-cloud-api 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.

从扫描运行的位置获取发现的问题：

OSS CLI —
```
strix_runs/<运行名称>/
```
目录下的产物：
- ```
vulnerabilities/*.md
```
  — 每个文件对应一个问题：包含描述、严重程度、PoC步骤或脚本、受影响的代码位置以及修复指导。
- ```
vulnerabilities.json
```
  — 以JSON格式存储的相同问题信息（包含ID、严重程度、CWE/CVE、带有
```
fix_before
```
  /
```
fix_after
```
  修复建议的
```
code_locations
```
  ，若有提供）。

Cloud (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

。认证相关内容请查看strix-cloud-api技能。

按严重程度排序处理优先级：严重→高→中→低。每个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
```
代码片段——可将其作为参考，但不要直接照搬。

常见问题类型及预期修复方案：injection（注入）→ 在数据接收端使用参数化/转义；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

修复完成后，针对修复区域重新扫描，确认问题已解决。可在原扫描环境（或两者都选）中进行验证：

OSS CLI:

bash

undefined

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)

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`：预算耗尽会导致状态为`"stopped"`，而因预算警告正常结束的扫描会记录`"completed"`但覆盖范围不全。请为验证分配足够的预算，优先重新运行特定PoC作为最可靠的验证信号。

**Cloud:** 使用相同配置重新扫描并轮询结果，确认问题不再出现：
```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.

或者，若云扫描来自仓库/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无法再复现）。报告中绝不要包含有效的密钥；若存在密钥泄露，需说明必须进行密钥轮换。

strix-fix-findings

Original

Translation

Fix Strix findings and verify

修复Strix发现的问题并验证

1. Triage

1. 分类处理

2. Fix

2. 修复

3. Verify by re-running Strix

3. 重新运行Strix进行验证

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

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

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

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

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.

HEAD would be HEAD, giving an empty diff and a falsely clean result.

origin/HEAD can be a dangling symbolic ref — keep it only if its target exists.

origin/HEAD can be a dangling symbolic ref — keep it only if its target exists.

No silent fallback: a guess like HEAD~1 would cover only the last commit of a

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

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

(or use the focused --instruction verification below, which needs no diff base).

Or re-test with the original finding as focus (no diff base needed)

Or re-test with the original finding as focus (no diff base needed)

poll GET /scans/$new_id until completed, then check its vulnerabilities[]

poll GET /scans/$new_id until completed, then check its vulnerabilities[]

4. Report

4. 报告