关于 fix-security-vulnerabilities-with-strix
本技能用于分诊 Strix 安全发现、修复根因并通过重新扫描验证，适合处理 OSS 命令行工具或 Strix Cloud 结果的开发者。
主要功能
- 01读取命令行产物或云端发现
- 02按严重程度安排修复顺序
- 03依据 PoC 步骤复现问题
- 04针对根因实施最小修复
- 05通过重新扫描和测试验证更改
适用场景
- 01修复代码库中已验证的漏洞
- 02查看云端发现并更新其状态
- 03确认修复后 PoC 不再复现
- 04检查修复是否影响项目功能
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/fix-security-vulnerabilities-with-strix确认已加载。
详细介绍
修复 Strix 发现的问题并验证
将已验证的 Strix 发现转化为精简、正确的修复，并通过重新扫描证明修复有效。
1. 分类处理
从扫描运行的位置获取发现的问题：
- OSS CLI —
strix_runs/<run-name>/中的产物：vulnerabilities/*.md— 每个文件包含一个发现的问题：描述、严重性、PoC 步骤或脚本、受影响的代码位置以及修复建议。vulnerabilities.json— 相同发现问题的 JSON 格式数据（ID、严重性、CWE/CVE、code_locations，以及可用时的fix_before/fix_after建议）。
- Cloud（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）。每条发现都包含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标记。有关strix cloud login和作用域，请参阅 managed-pentesting-with-strix 技能。
按严重性安排处理顺序：critical → high → medium → low。Strix 的每项发现都已通过可运行的概念验证（PoC）验证，因此，未经自行重新测试 PoC，不要将发现判定为误报。
2. 修复
针对每项发现：
- 可行时，使用发现文件中的 PoC 复现问题。
- 修复根本原因，而非针对特定载荷修补（对每个查询进行参数化，而不是屏蔽某个字符串；在处理程序中强制执行授权，而不是隐藏端点）。
- 优先使用框架内置的防护措施（ORM 参数化、模板自动转义、CSRF 中间件、集中式授权），而不是临时拼凑的净化逻辑。
- 保持差异最小，并沿用仓库已有模式。发现文件通常包含
fix_before/fix_after代码片段，可将其作为起点，但不要照搬。
常见发现类型及预期修复：注入 → 在数据接收点进行参数化/转义；IDOR/访问控制失效 → 执行对象级授权检查；SSRF → 使用允许列表并阻止内部网段；XSS → 使用与上下文相关的输出编码 + CSP；密钥泄露 → 轮换密钥并将其从代码/历史记录中移除；身份验证问题 → 修复服务端检查（绝不要只在客户端修复）。
3. 重新运行 Strix 进行验证
修复后，针对已修复的区域重新扫描，并确认该问题已消失。在扫描所用的环境中验证（也可以在两个环境中都验证）：
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
# 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 中的状态是否为已完成，并将 llm_usage.cost 与 --max-budget 进行比较：硬性预算限制会导致 status: "stopped"，而在预算警告下结束的运行会记录为 "completed"，但覆盖范围不完整。确保验证有足够预算以完成，并优先重新运行特定 PoC，将其作为实际判定依据。
**Cloud：**使用相同配置重新扫描并再次轮询，然后确认该问题不再出现：
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[]
或者，如果 Cloud 扫描来自仓库/PR，则在修复分支上触发新的 PR 审查（POST /pr-reviews/start）。平台也可以直接重新测试单项发现：POST /api/v1/vulnerabilities/{vulnerabilityId}/retest。
- 如果 PoC 是简单的请求/脚本，也要手动重新运行——这是最快的验证方式。
- 运行项目自己的测试套件，确保修复没有破坏功能。
4. 报告
按发现的问题逐项总结：严重性、根本原因、采取的修复（文件:行号）、验证结果（重新扫描未发现问题 / PoC 无法再复现）。报告中绝不要包含仍有效的密钥；如果密钥已泄露，请说明需要轮换。