mcpField
S
strix-fix-findings

strix-fix-findings

github.com/usestrix安全72.6k133 次安装1 天前更新
代码仓库

关于 strix-fix-findings

strix-fix-findings 是根据 Strix 已验证发现修复漏洞并复扫确认的技能，面向负责安全问题处置的开发人员。它涵盖发现分级、根因修复、CLI 或云端复测及结果汇报。

主要功能

  1. 01从 CLI 或云端获取发现
  2. 02按严重程度排列处理顺序
  3. 03依据 PoC 重现并修复根因
  4. 04通过复扫或 PoC 验证修复
  5. 05汇总修复与验证结果

适用场景

  1. 01处理 Strix 报告中的漏洞
  2. 02用 PoC 复现并确认问题根因
  3. 03复扫已修复的代码或 PR
  4. 04记录修复位置及验证结果

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/usestrix/strix --skill strix-fix-findings

安装后在 Claude Code 中输入/strix-fix-findings确认已加载。

详细介绍

修复 Strix 发现的问题并验证

将已验证的 Strix 发现转化为精简、正确的修复，并通过重新扫描证明修复有效。

1. 分类

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

  • OSS CLI — strix_runs/<run-name>/ 中的产物：
    • 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。身份验证信息请参阅 strix-cloud-api 技能。

按严重程度安排处理顺序：严重 → 高 → 中 → 低。每项 Strix 发现都经过有效概念验证，因此除非你亲自重新测试 PoC，否则不要将发现判定为误报。

2. 修复

对于每项发现：

  1. 在可行时，使用发现文件中的 PoC 复现问题。
  2. 修复根本原因，而非针对特定载荷修补（例如，对所有查询进行参数化，而不是屏蔽某个字符串；在处理程序中实施授权，而不是隐藏端点）。
  3. 优先使用框架内置的防护（ORM 参数化、模板自动转义、CSRF 中间件、集中式授权），而非临时编写的清理逻辑。
  4. 保持差异精简，并遵循仓库现有模式。发现文件通常包含 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，作为判定结果的依据。

云端： 使用相同配置重新扫描并再次轮询，然后确认该问题不再出现：

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 是简单请求/脚本，也要手动重新运行——这是最快的验证方式。
  • 运行项目自带的测试套件，确保修复没有破坏功能。

4. 报告

按发现的问题逐项总结：严重程度、根本原因、已应用的修复（文件:行号）、验证结果（重新扫描未发现问题 / PoC 无法再复现）。报告中绝不包含有效机密信息；如果机密信息已泄露，应说明必须进行轮换。

评论

支持 Markdown