fix-security-vulnerabilities-with-strix

Strix の指摘を修正して検証する

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

1. トリアージ

スキャンを実行した場所から指摘を取得します。

• OSS CLI — strix_runs/<run-name>/ 内のアーティファクト：
  • vulnerabilities/*.md — 1 ファイルにつき 1 件の指摘。説明、重大度、PoC の手順またはスクリプト、影響を受けるコードの場所、修正ガイダンスが記載されています。
  • vulnerabilities.json — 同じ指摘を JSON 形式で記録したものです（ID、重大度、CWE/CVE、利用可能な場合は fix_before／fix_after の提案を含む code_locations）。
• 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 を再テストせずに誤検知として退けないでください。

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 を再実行することを優先してください。

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