fix-security-vulnerabilities-with-strix

用途

该技能面向已由 Strix 完成渗透测试、需要将验证过的漏洞发现转化为最小且正确的修复，并通过重新扫描证明修复生效的场景。Strix 可以是开源 CLI，也可以是 app.strix.ai 云服务。

主要能力

分流：从扫描产出位置获取发现。
- 开源 CLI：产物位于 strix_runs/<run-name>/。其中 vulnerabilities/*.md 每个文件一条发现，包含描述、严重程度、PoC 步骤或脚本、受影响代码位置、修复指引；vulnerabilities.json 是相同发现的 JSON 形式（ids、severity、CWE/CVE、code_locations，以及在可用时给出的 fix_before/fix_after 建议）。
- 云端（app.strix.ai）：用 CLI 拉取，例如 strix cloud vulns list --scan-id <scan-id> --json，或 strix cloud scans get <scan-id> --json | jq '.vulnerabilities'，或 strix cloud vulns list --severity critical org-wide。每条发现带有 severity、cwe、endpoint、method、impact、technical_analysis、poc_description、poc_script_code，对于代码类发现还有 code_file/code_diff/code_before/code_after。修复经验证后，用 strix cloud vulns update <id> --status fixed 标记。登录与 scope 相关操作参见 managed-pentesting-with-strix 技能。
- 按严重程度排序：critical → high → medium → low。每条 Strix 发现都经过可用 PoC 验证，因此不要在没有自行重测 PoC 的情况下将其当作误报排除。
修复：对每条发现，尽量用发现文件中的 PoC 复现；修复根因而非特定载荷（例如为每个查询做参数化，而不是封堵某个字符串；在处理函数中实施授权，而不是隐藏端点）；优先使用框架内置防御（ORM 参数化、模板自动转义、CSRF 中间件、集中式授权）而非临时性的清洗；保持 diff 最小并沿用仓库既有模式。发现文件常含 fix_before/fix_after 片段，可作为起点而非照搬。

常见发现类别与预期修复：注入 → 在汇聚点参数化/转义；IDOR/访问控制失效 → 对象级授权检查；SSRF → 允许名单 + 阻断内网网段；XSS → 上下文感知的输出编码 + CSP；密钥泄露 → 轮换密钥并从代码/历史中移除；认证问题 → 修服务端检查（绝不在客户端）。

通过重新运行 Strix 验证：修复后，将重扫范围限定在修复区域并确认发现已消失。在扫描所用环境（或两者）中验证。

开源 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
# 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

退出码：2 表示仍有发现（读取新的 strix_runs/<run>/vulnerabilities/ 并迭代）；0 表示所分析范围内干净。在信任 0 之前，确认运行未被提前中断——检查 run.json 是否为 completed 状态，并将其 llm_usage.cost 与 --max-budget 对比：硬性预算中断会留下 status: "stopped"，但因预算警告而收尾的运行会记录为 "completed" 且覆盖不完整。给验证留足预算，并优先重放具体 PoC 作为真值信号。

云端：用相同配置重跑并重新轮询，然后确认该发现不再出现：

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[]

或者，如果云端扫描来自仓库/PR，在修复分支上触发一次新的 PR 审查（POST /pr-reviews/start）。平台也可直接重测单条发现：POST /api/v1/vulnerabilities/{vulnerabilityId}/retest。

当 PoC 是简单请求/脚本时，也手动重放它——这是最快的信号。

运行项目自身的测试套件，确保修复未破坏行为。

报告：按发现逐条汇总：严重程度、根因、所应用的修复（file:line）、验证结果（重扫干净 / PoC 不再复现）。报告中绝不要包含真实密钥；若有密钥泄露，须说明需要进行轮换。

技能介绍

用途

主要能力