strix-fix-findings

Strix の検出結果を修正して検証する

検証済みの Strix の検出結果に対して、最小限かつ適切な修正を行い、再スキャンして有効性を確認します。

1. トリアージ

スキャンを実行した場所から検出結果を取得します。

• OSS CLI — strix_runs/<run-name>/ にある成果物：
  • vulnerabilities/*.md — ファイルごとに 1 件の検出結果が記載されています。説明、重大度、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 スキルを参照してください。

重大度の高い順に作業します：critical → high → medium → low。Strix の検出結果はすべて、動作する概念実証（PoC）によって検証済みです。自分で PoC を再テストせずに、誤検出として退けないでください。

2. 修正

各検出結果に対して、次の手順を実施します。

1. 可能であれば、検出結果のファイルにある PoC を使って再現します。
2. 特定のペイロードではなく、根本原因を修正します（例：1 つの文字列をブロックするのではなく、すべてのクエリをパラメーター化します。エンドポイントを隠すのではなく、ハンドラーで認可を強制します）。
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 を再実行することを優先してください。

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 で再現しなくなった）をまとめます。報告に有効なシークレットを記載しないでください。シークレットが漏えいした場合は、ローテーションが必要であることを明記してください。