snyk-fix

Snyk Fix（オールインワン）

包括的なセキュリティ修正ワークフロー：解析 → スキャン → 分析 → 修正 → 検証 → 概要 →（任意）PR

モード：

• 単一モード（デフォルト）：一度に1種類の脆弱性を修正します（同じファイル内のすべてのインスタンス）
• バッチモード：優先順位に従って複数の脆弱性を修正します（「all」、「batch」、重大度フィルター、または件数によって起動）

---

フェーズ 1：入力の解析

ユーザー入力を解析して、以下を抽出します：

• mode：単一（デフォルト）またはバッチ
• scan_type：code、sca、または both（文脈から推定）
• target_vulnerability：特定の問題 ID、CVE、パッケージ名、ファイル、または脆弱性の種類
• target_path：ファイルまたはディレクトリ（デフォルトはプロジェクトのルート）
• severity_filter / max_fixes：バッチモード用（デフォルトの最大件数：20）

モードとスキャンタイプの検出

シグナル	モード	スキャンタイプ
「all」、重大度フィルター、件数（「top 5」など）、または「batch」	バッチ	both
特定の脆弱性 ID、単一の種類、ファイルの指定、またはバッチを示す語句がない場合	単一（デフォルト）	—
明示的な「code」／「sast」／「static」	—	code
明示的な「sca」／「dependency」／「package」／パッケージマネージャー名	—	sca
SNYK- または CVE- ID の指定	—	both
脆弱性の種類（XSS、SQL インジェクション、パストラバーサルなど）またはファイルの指定	—	code
パッケージ名の指定	—	sca
ヒントなし	—	both（最優先の問題）

---

フェーズ 1B：バッチモードの計画（単一モードの場合はスキップ）

1. プロジェクトのルートで mcp_snyk_snyk_code_scan と mcp_snyk_snyk_sca_scan の両方を実行します。
2. ユーザーが指定した重大度、種類、パス、または件数で絞り込みます。
3. 脆弱性の種類ごとにグループ化します（Code は同じ ID とファイル、SCA は同じパッケージ）。Critical → High → Medium → Low の順に並べ、同じ優先度内では修正可能な問題を優先します。
4. 修正計画を番号付きの表（インデックス、種類、重大度、対象、インスタンス数）で表示し、変更予定のファイル／パッケージ数も示します。続行する前に、ユーザーの確認を待ってください。
   • ユーザーが「adjust」と入力した場合：計画の変更を許可します。
5. 順番に修正を実行します（各項目についてフェーズ 3 または 4 → フェーズ 5 で検証 → 結果を記録）。失敗した場合：stop_on_failure=true なら停止し、そうでなければ続行します。
6. すべての試行が完了したら、フェーズ 6B に進みます。

バッチの上限：脆弱性は最大 20 件、変更するファイルは最大 15 個、項目ごとの修正試行は最大 3 回です。

---

フェーズ 2：検出

ステップ 2.1：スキャンを実行

対象パスを指定してスキャンを実行します。例：

# Code scan
mcp_snyk_snyk_code_scan:
  path: "/absolute/path/to/project"   # or subdirectory for targeted scans

# SCA scan
mcp_snyk_snyk_sca_scan:
  path: "/absolute/path/to/project"   # always project root (manifest location)

• Code：対象パスに対して mcp_snyk_snyk_code_scan を実行
• SCA：プロジェクトのルートに対して mcp_snyk_snyk_sca_scan を実行
• 両方：並行して実行

ステップ 2.2：対象を選択

• ユーザーが指定した場合：一致する問題を検索します。見つからない場合は報告して停止します。
• 指定がない場合：Critical+exploit > Critical > High+exploit > High > Medium > Low の順に、最も優先度の高い種類を選択します。修正可能な問題を優先します。

ステップ 2.3：インスタンスをグループ化（Code のみ）

脆弱性の種類を選択したら、同じファイル内にある、同じ Snyk ID のインスタンスをすべて収集します。まとめて修正します。

ステップ 2.4：対象を記録

種類（Code／SCA）、ID、重大度、タイトルを簡潔に表示します。Code の場合はインスタンス数とファイル／行の表、SCA の場合はパッケージ、修正バージョン、依存関係のパスを表示します。

ステップ 2.5：修正方法を確認（SCA のみ）

⚠️ スキャン結果に、選択した SCA 脆弱性の修正バージョンまたはアップグレードパスが報告されていない場合は、フェーズ 4 に進まないでください。 Snyk が推奨する修正方法を提示していないとき、エージェントは独自に修正方法を探したり、作り出したりしてはいけません。

代わりに、修正方法なしのレポートを作成して停止します：

## No Fix Available

| Vulnerability | [Title] |
|---------------|---------|
| **ID** | [Snyk Issue ID] |
| **Severity** | [Critical / High / Medium / Low] |
| **Package** | [package@current_version] |
| **Dependency Path** | [direct / transitive via X → Y → Z] |

### Why No Fix Was Applied
Snyk does not report a fix version or upgrade path for this vulnerability.
The agent will not attempt to resolve issues where no known fix exists.

### Alternatives to Consider
- Monitor for a future fix release from the package maintainer
- Evaluate replacing the package with a maintained alternative
- Apply a manual workaround if the vulnerability context allows it
- Accept the risk and document in your security policy

このレポートを作成した後：

• fixedExistingIssuesCount: 0 を指定して mcp_snyk_snyk_send_feedback を送信します
• ファイルを変更しないでください
• 停止します

---

フェーズ 3：修正（Code の脆弱性）

ステップ 3.1：理解

脆弱性のあるすべての箇所を読みます。種類（SQL インジェクション、XSS、パストラバーサル、コマンドインジェクション、機密データの漏えい、ハードコードされたシークレット、暗号化の問題など）を特定します。Snyk の修正ガイダンスを確認します。

ステップ 3.2：計画

文書化する項目：脆弱性の種類、根本原因、修正方法、セキュリティメカニズム、インスタンス数。

一般的なパターン：

• SQL インジェクション → パラメーター化クエリ
• コマンドインジェクション → 入力検証とエスケープ、またはシェルを使用しない
• パストラバーサル → 正規化し、許可されたベースパスに対して検証する
• XSS → コンテキストに応じた出力エンコード／サニタイズ
• ハードコードされたシークレット → 環境変数／シークレットマネージャーに移す

ステップ 3.3：すべてのインスタンスに修正を適用

• ファイルの末尾から先頭に向かって修正する（行番号のずれを防ぐため）
• 変更は最小限にする。標準ライブラリ／フレームワークのセキュリティ機能を使用する
• 同一の修正パターンを共有するインスタンスが3つ以上ある場合は、共通ヘルパーを作成する
• 自明でない箇所には、セキュリティに関するコメントを追加する
• 無関係なコードのリファクタリングや、ビジネスロジックの変更は行わない

---

フェーズ 4：修復（SCA 脆弱性）

コードの脆弱性の場合（フェーズ 3 で対応済み）は、フェーズ 5 に進んでください。

ステップ 4.1：修復方針の決定

依存関係のパスを分析し、該当する方針を決定します。先に進む前に、次の3つの方針から必ず1つを選択してください。

方針 A — 直接アップグレード 脆弱なパッケージがプロジェクトのマニフェストで直接依存関係として指定されています。脆弱性が修正されたバージョンにアップグレードします。

方針 B — 親依存関係のアップグレード 脆弱なパッケージは推移的依存関係です。直接依存関係（親）の新しいバージョンによって、修正済みバージョンの推移的依存関係が取り込まれます。親依存関係をアップグレードします。

方針 C — 推移的依存関係の修正 脆弱なパッケージは推移的依存関係ですが、修正済みの推移的依存関係を取り込む親のバージョンはありません。エコシステムで利用可能な、影響が最も小さい方法を使って、推移的依存関係を修正済みバージョンに解決します。

選び方：

1. 脆弱なパッケージはプロジェクトのマニフェストで直接指定されていますか？

   • はい → 方針 A
   • いいえ → ステップ 2 に進む

2. 脆弱な推移的依存関係を取り込んでいる直接依存関係（親）を特定します。親の利用可能なバージョンのいずれかによって、脆弱な推移的依存関係が修正済みバージョンに解決されますか？

   • はい → 方針 B（親をアップグレード）
   • いいえ → 方針 C（推移的依存関係を修正）

アプリケーションが推移的依存関係を直接インポートまたは使用している場合（親を介した使用のみではない場合）は、その旨を記録してください。これは、方針 C の破壊的変更の分析に影響します。

選択した方針を記録します：

## Remediation Strategy
- **Strategy**: [Direct Upgrade | Parent Upgrade | Transitive Fix]
- **Target package to change**: [package@current → package@target]
- **Parent dependency** (if Parent Upgrade or Transitive Fix): [parent@current]
- **Manifest file**: [path to manifest]

Step 6.2（またはバッチモードの Step 6B.2）の snyk_send_feedback 呼び出しにある strategy フィールドでは、この文字列をそのまま使用してください。

ステップ 4.2：破壊的変更の評価

⚠️ 変更を適用する前に、必ず mcp_snyk_snyk_breakability_check を実行してください。 ツールが利用できない場合、エラーが発生した場合、または LOW／MEDIUM／HIGH のリスクレベルが返されない場合は、ステップ 4.2a に進んでください。

マニフェストで実際に変更するパッケージを指定して、mcp_snyk_snyk_breakability_check を呼び出します。

方針	破壊的変更の確認対象
A（直接アップグレード）	アップグレードする直接依存関係
B（親依存関係のアップグレード）	アップグレードする親依存関係
C（推移的依存関係の修正）	新しいバージョンに解決する推移的依存関係

破壊的変更のリスク判断ツリー

破壊的変更のリスク結果（LOW／MEDIUM／HIGH）は、一般的な可能性の評価であり、この特定のプロジェクトで実際に破壊的変更が発生することを確認するものではありません。この結果を基に、次のアクションを決定してください。

対話型実行と自律型実行：人間が介在する場合（対話型セッション）は、トレードオフを提示し、リスクが HIGH の場合は確認を求めてください。自律的に実行する場合（バックグラウンドエージェントなど、人間が対応できない場合）、エージェントは脆弱性の深刻度、破壊的変更のリスク、破壊的変更の詳細など、人間が判断する場合と同じ根拠を評価して、自ら判断し、出力に判断理由を記録する必要があります。自律型エージェントは、応答が得られない入力を待って処理を止めてはいけません。

戦略 A（直接アップグレード）と戦略 B（親パッケージのアップグレード）：

リスク	アクション
LOW	アップグレードを自動適用します。ステップ 4.4 に進みます。
MEDIUM	アップグレードを自動適用します。修復の概要に破壊的変更の概要と判断理由を記録します。
HIGH	対話型：トレードオフ全体（脆弱性の詳細、破壊的変更の概要、具体的な変更案）を提示し、続行するかどうかをユーザーに確認します。自律型：トレードオフ全体を評価し、適用するか、完全なアドバイザリ（フェーズ 4a）を作成するかを判断して、その理由を記録します。

**戦略 B から戦略 C へのフォールバック：**戦略 B の破壊的変更リスクが HIGH で、ユーザーまたはエージェントが続行しないと判断した場合は、戦略 C にフォールバックします。推移的なバージョン変更に対して mcp_snyk_snyk_breakability_check を再実行し、以下の戦略 C の判断ツリーに従ってください。このフォールバックが発生した場合は、ステップ 6.2 に進む前に、ステップ 4.1 の「選択した戦略を記録する」テンプレートを Transitive Fix を使って再記録してください。

戦略 C（推移的な修正）：

リスク	アクション
LOW	修正を自動適用します。ステップ 4.4 に進みます。
MEDIUM	アップグレードを自動適用します。修復の概要に破壊的変更の概要と判断理由を記録します。
HIGH	対話型：トレードオフ全体を提示し、続行するかどうかをユーザーに確認します。脆弱性の深刻度が Critical で、既知のエクスプロイトがある場合は、緊急性を強調してください。自律型：トレードオフ全体を評価し、適用するか、完全なアドバイザリ（フェーズ 4a）を作成するかを判断して、その理由を記録します。

Step 4.2a: 破壊可能性のフォールバック — Semver と使用状況の分析

このステップは、mcp_snyk_snyk_breakability_check が利用できない場合（ツールが見つからない、エラーになる、タイムアウトする）、または LOW/MEDIUM/HIGH のリスクレベルを含まない応答を返す場合（例：「利用可能な追加の破壊可能性コンテキストはありません」）に有効になります。破壊可能性チェックが有効なリスクレベルを返した場合は、このステップ全体をスキップしてください。

破壊可能性データを利用できない場合は、Semver 上の差分とコードベースでの使用状況を組み合わせて代替のリスクレベルを導き出します。

1. 現在のバージョンと対象バージョンの Semver 上の差分を判断します。

   • パッチバージョンの更新（例：1.2.3 → 1.2.5）：本質的なリスクは最も低い
   • マイナーバージョンの更新（例：1.2.3 → 1.3.0）：本質的なリスクは中程度
   • メジャーバージョンの更新（例：1.2.3 → 2.0.0）：本質的なリスクは最も高い

2. アップグレード対象パッケージの直接的な使用箇所をコードベース内で検索します。プロジェクトの言語やエコシステムに適したパターンを使って、インポート、require、include、その他の依存関係の参照を探します。エージェントはエコシステムに基づいて適切な検索パターンを判断します。ハードコードされたパターンは使用しないでください。

3. 2 つのシグナルを組み合わせて、代替のリスクレベルを導き出します。

Semver 上の差分	直接的な使用なし	軽微な使用	多用／複雑な使用
パッチ	LOW	LOW	LOW
マイナー	LOW	MEDIUM	MEDIUM
メジャー	HIGH	HIGH	HIGH

4. 代替のリスクレベルを、Step 4.2 と同じ破壊可能性の判断ツリーに適用します。別のコードパスは設けず、同じしきい値とアクションを適用してください。

重要：代替のリスクレベルを使用した場合は、修正の概要（Phase 6）にその旨を記載し、リスク評価が破壊可能性データではなくコードベースの分析から導き出されたことをユーザーに知らせてください。

Step 4.3: バージョンの選択

脆弱性を修正できるバージョンが複数ある場合、バージョン番号が最も小さいものを安易に選ばないでください。次の優先順位で選択します。

1. 対象の脆弱性を修正する
2. 破壊可能性のリスクが最も低い（必要に応じて候補に対して mcp_snyk_snyk_breakability_check を実行する）
3. バージョン番号が最も小さい（同順位の場合にのみ使用）

Step 4.4: 修正の適用

破壊可能性の判断で適用が許可された場合（自動適用、またはユーザー／エージェントによる確認）にのみ、このステップに進んでください。

戦略 A（直接アップグレード）： マニフェストのバージョンを更新し、エコシステムのインストールコマンド（npm install pkg@version、yarn upgrade、go get、pip install、mvn dependency:resolve など）を実行します。ファイルの書式とコメントは保持してください。

戦略 B（親依存関係のアップグレード）： マニフェスト内の親依存関係のバージョンを更新し、エコシステムのインストールコマンドを実行します。インストール後、解決された推移的依存関係が修正済みのバージョンになっていることを確認してください。

戦略 C（推移的依存関係の修正）： リゾルバーが推移的依存関係の修正済みバージョンを選択するようにする、影響が最も小さい方法を使います。具体的な方法はエコシステムによって異なります。どのエコシステムにも共通する順序があるとは考えないでください。

1. まずリゾルバーのみを更新する：ロックファイルを更新するか、対象の脆弱なパッケージに対するエコシステムの更新／解決コマンドを実行します。修正済みバージョンが既存の制約で許可されている場合に適切な方法です。
2. これで解決しない場合は、エコシステムとリポジトリの構成を確認してから、適切なネイティブのリゾルバー制御方法を選びます。トップレベルの制約／宣言、中央の依存関係管理エントリ、強制／オーバーライド／解決、除外、置換などがあります。
3. 有効な範囲が最も狭い方法を優先する。通常の宣言や、より狭い範囲の除外でリゾルバーに修正済みバージョンを選択させられない場合にのみ、より強いオーバーライド／強制／置換を使います。
4. バージョンのハードピンは最終手段としてのみ使用します。

参考：一般的なインストール／解決コマンド

パッケージマネージャー	コマンド
npm（メジャーアップグレード）	npm install <pkg>@<version>
npm（マイナー／パッチ）	npm install
yarn	yarn install or yarn upgrade <pkg>@<version>
pip	pip install -r requirements.txt
maven	mvn dependency:resolve

この表はすべてを網羅しているわけではありません。プロジェクトのエコシステムに適したコマンドを使用してください。

インストールに失敗した場合：

• サンドボックス／権限の問題の場合：権限を昇格して再試行します
• 依存関係の競合の場合：別のバージョンを試すか、修正不可能として記録します
• 解決に完全に失敗した場合は、マニフェストの変更を元に戻します
• 失敗の理由を記録します

---

フェーズ 4a：完全なアドバイザリー — SCA の適用なし経路

SCA の修正を適用しないと判断した場合に、このフェーズに進みます。ユーザーが辞退した場合も、（自律モードで）エージェントがリスクはメリットを上回ると判断した場合も対象です。

変更を加える代わりに、アドバイザリーを作成します。

アドバイザリーの出力形式

## Security Advisory — Manual Action Required

### Vulnerability
- **ID**: [Snyk Issue ID]
- **Severity**: [Critical | High | Medium | Low]
- **Package**: [vulnerable_package@current_version]
- **Title**: [vulnerability title]

### Why This Was Not Auto-Applied
[1-2 sentences: e.g., "The required transitive fix from [email protected] to [email protected] has a HIGH
breaking change risk. The changelog indicates removed APIs and changed default behavior
that may affect consumers."]

### Breaking Change Details
[Summary from mcp_snyk_snyk_breakability_check — what changed between versions, which APIs were
removed/renamed/modified, migration notes if available]

### Exact Changes Required
To apply this fix manually, make the following changes:

**1. Manifest change** ([path/to/manifest]):
[Exact content to add or modify — the override/resolution entry or version bump]

**2. Regenerate lockfile**:
[Exact command to run]

**3. Validate**:
[Command to re-run SCA scan and tests]

### Alternatives
- Wait for [parent_package] to release a version that includes the fixed transitive
- Evaluate replacing [vulnerable_package] with an alternative
- Accept the risk and document in your security policy

アドバイザリーを作成した後：

• ファイルを変更してはいけません
• フェーズ 5 に進んではいけません
• fixedExistingIssuesCount: 0 を指定して mcp_snyk_snyk_send_feedback を送信します
• 停止します

---

フェーズ 5：検証

ステップ 5.1：スキャンを再実行する

フェーズ 2 と同じスキャンを実行し（同一の path パラメーターを使用）、対象となるすべてのインスタンスが解決されていることを確認します。

コードの脆弱性 — インスタンスが残っている場合：

• 該当するインスタンスの修正を確認します
• 別の方法を試します
• インスタンスごとに最大 3 回まで試行し、その後は部分的な成功／失敗を報告します
• 新たな脆弱性が導入された場合は修正します（反復は最大 3 回）。クリーンな修正ができない場合は、すべての変更を元に戻して失敗を報告します

SCA の脆弱性 — 脆弱性が残っている場合：

• ロックファイルが適切に更新されたか確認します
• パッケージマネージャーの正確なバージョン指定構文を使って、バージョンを明示してインストールします
• 最大 3 回まで試行し、その後は停止して失敗を報告します

SCA のアップグレードによって新たな脆弱性が導入された場合：

• 新たな脆弱性の重大度が修正対象より低い場合：受け入れます（セキュリティが全体として向上します）
• 新たな脆弱性の重大度が修正対象と同等以上の場合：別のバージョンを試します。候補を試す前にそれぞれに対して mcp_snyk_snyk_breakability_check を実行し、リスクを評価せずに上位バージョンを試してはいけません。反復は最大 3 回です。
• クリーンなバージョンがない場合：元に戻し、修正不可能として報告します

ステップ 5.1a：追加で修正された問題（SCA のみ）

スキャンの実行前後を比較します。アップグレードによって解消された追加の脆弱性（ID、重大度、タイトル）を記録します。

ステップ 5.2：テストを実行する

プロジェクトのテスト（npm test、pytest など）を実行します。

コードの脆弱性の場合：

• 失敗した場合：テストを変更するよりも、修正方法の調整を優先します。テストの変更は、動作の正当な変更がある場合に限ります。最大 2 回まで試行します。

SCA の脆弱性の場合：

• 失敗した場合：ダウングレードするよりも、新しい API に合わせてコードを調整することを優先します。機械的な修正（インポート名やシグネチャの変更）のみ適用します。最大 2 回まで試行します。

ステップ 5.3：リントを実行する

設定されている場合はプロジェクトのリンターを実行し、新たに発生した書式の問題を修正します。

---

フェーズ 6：概要と PR プロンプト

ステップ 6.1：概要を表示する

以下を含む簡潔な修正概要を表示します。

• 脆弱性 ID、重大度、タイトル、CWE（コードの場合）またはパッケージのアップグレード（SCA の場合）
• インスタンス数／修正数と、インスタンスごとの状況（✅ 修正済み／⚠️ 部分的／❌ 失敗）
• 「修正内容」：コードスニペットを含めず、平易な文章で 2～3 文
• 検証テーブル：Snyk の再スキャン、ビルド、リント、テスト（✅／⚠️／❌）
• SCA の場合：戦略（直接／親／推移的）、破壊的変更のリスク（低／中／高）、リスクの根拠（Breakability Check／コードベースの使用状況分析）、破壊的変更の概要、アップグレードによって修正された追加の問題の一覧

最後に、視覚的に区切った PR プロンプトを表示します。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
## Should I create a PR for this fix? (yes / no)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ステップ 6.2：フィードバックを送信する

ステップ 6.1 の概要ですでに収集したデータを使用します。

mcp_snyk_snyk_send_feedback:
  fixedExistingIssuesCount: [total issues fixed]
  fixedIssueIds: [array of prefixed IDs fixed — "sast:<ID>" once per Code instance fixed,
    or "sca:<ID>" for the SCA vulnerability plus each additional issue fixed by the same
    upgrade (Step 5.1a)]
  fixedIssuesBySeverity: {critical: [count], high: [count], medium: [count], low: [count]}
  fixedIssuesByScanType: {sast: [count], sca: [count]} (Code fixes report sast only; SCA
    fixes report sca only)
  outcome: "applied"
  breakabilityRisk: [LOW | MEDIUM | HIGH | unknown] (SCA only, from Step 4.2/4.2a — omit for Code)
  breakabilityRiskSource: [api | heuristic] (SCA only — omit for Code)
  strategy: [Direct Upgrade | Parent Upgrade | Transitive Fix] (SCA only, from Step 4.1 — omit for Code)
  testsPassed: [true | false] (from Step 5.2)
  preventedIssuesCount: 0
  path: [absolute project path]

ステップ 6.3：ユーザーの応答を待つ

重要：ユーザーが明示的に確認するまで、先に進んではいけません。

---

フェーズ 6B：バッチ概要（バッチモードのみ）

ステップ 6B.1：概要

全体の結果（試行済み／修正済み／部分的に修正／失敗／スキップ）、深刻度別の内訳（修正済みと未修正）、コードおよび SCA 脆弱性の項目ごとの詳細な結果、変更したファイル、検証結果、未修正の問題とその理由をまとめた表を表示します。

最後に以下を出力します：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
## Should I create a single PR for all these fixes? (yes / no)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

ステップ 6B.2：バッチフィードバックの送信

mcp_snyk_snyk_send_feedback:
  path: [project root]
  fixedExistingIssuesCount: [total across all vulns]
  fixedIssueIds: [prefixed ID of every fixed item — "sast:<ID>" for each fixed Code item,
    "sca:<ID>" for each fixed SCA item; array length matches fixedExistingIssuesCount]
  fixedIssuesBySeverity: {critical: [count], high: [count], medium: [count], low: [count]}
  fixedIssuesByScanType: {sast: [count], sca: [count]}
  outcome: "applied"
  testsPassed: [true | false] (overall batch test result)
  breakabilityRisk / breakabilityRiskSource / strategy: include only if exactly one SCA
    item was fixed in this batch (so a single value applies); omit if zero or multiple SCA
    items were fixed, since these are single-value fields and a mixed batch can span
    different risks/strategies per item
  preventedIssuesCount: 0

ステップ 6B.3：バッチ PR

ブランチ：fix/security-batch-YYYYMMDD または fix/security-critical-high-batch。 デフォルト：すべての変更を 1 つのコミットにまとめます（ユーザーが希望する場合は、脆弱性ごとのコミットも提示します）。 PR 本文：コード修正の概要表（脆弱性、ファイル、CWE、深刻度）、依存関係のアップグレード（パッケージ、変更前→変更後、修正した CVE）、検証チェックリスト、各修正を個別に検証した旨の注記。

---

フェーズ 7：PR の作成（確認があった場合）

ステップ 7.1：Git のステータスを確認

git status

未コミットの変更があること、およびそれらがセキュリティ修正に関連していることを確認します。変更がない場合は、その旨を報告して STOP します。

ステップ 7.2：ブランチの作成

形式：fix/security-<identifier>（例：fix/security-SNYK-JS-LODASH-1018905、fix/security-cwe-79-xss、fix/security-path-traversal-server）。

git checkout -b fix/security-<identifier>

ステップ 7.3：ステージングとコミット

セキュリティ修正に関連するファイルのみをステージングします。無関係な変更、IDE ファイル、ビルド成果物はステージングしないでください。

git add <files>
git commit -m "fix(security): <description>

Resolves: [Snyk ID or CVE]
Severity: [Critical/High/Medium/Low]"

ステップ 7.4：プッシュと PR の作成

git push -u origin fix/security-<identifier>
gh pr create --title "Security: <title>" --body "<body>" --base main

--label フラグは使用しないでください。

PR 本文には、脆弱性の詳細（ID、深刻度、種類）、変更内容、変更したファイル、検証チェックリスト（Snyk スキャンが成功すること、テストが成功すること、新たな脆弱性が持ち込まれていないこと）を記載します。

ステップ 7.5：確認情報の出力

PR の URL、ブランチ、タイトル、次の手順（レビュー、レビューの依頼、承認後のマージ）を表示します。

---

エラー処理

状況	対応
認証エラー	mcp_snyk_snyk_auth を実行して、1 回再試行します。それでも失敗する場合は STOP します
スキャンのタイムアウト／失敗	1 回再試行します。それでも失敗する場合は STOP して報告します
脆弱性が見つからない	明確に報告して STOP します。推測したり、別の問題を修正したりしないでください
修正不可能なコードの脆弱性	コンテキストを含む TODO コメントを追加し、手動での修正案とともに報告します。不完全または破損した修正は行いません
SCA — 修正方法がない	ステップ 2.5 に従います。「修正方法なし」レポートを作成して STOP します
SCA — 修正が拒否またはスキップされた	正常に終了します。まだ表示していない場合は完全なアドバイザリ（フェーズ 4a）を作成し、fixedExistingIssuesCount: 0 を指定してフィードバックを送信し、STOP します
部分的な成功（コード）	成功した修正は保持し、修正できなかった箇所には TODO を追加し、内訳とともに部分的な成功を報告します
Git リポジトリではない	STOP します。PR を作成できません
ブランチがすでに存在する	タイムスタンプを付けた一意のブランチ名を生成します
gh が認証されていない	gh auth login を提案します

ロールバックの条件（次の場合はすべての変更を元に戻します）：

• 3 回試行しても適切なコード修正ができない（または新たな脆弱性が持ち込まれる）
• 機械的な修正を 2 回試みても、テストの失敗を妥当に解決できない
• 修正にビジネスロジックの変更が必要となる
• 依存関係の解決に完全に失敗する

---

制約

単一モード：1 回の実行につき、1 種類の脆弱性（すべての該当箇所）を修正します。変更は最小限にします。新たな脆弱性を持ち込んではなりません。テストは成功する必要があります。スコープの拡大やリファクタリングは禁止です。必ず PR の作成を促します。

SCA 固有（単一モードとバッチモード）：

• SCA 修正はすべて破壊可能性の確認を通す必要があります — mcp_snyk_snyk_breakability_check を先に実行し、リスクベースの判断ツリーに従うまでは、SCA のアップグレードを適用しないでください
• 高リスクの場合は確認が必要です — 対話セッションでは、高リスクの修正にはユーザーの明示的な確認が必要です。中リスクの修正は、判断理由を記録したうえで自動適用します。ステップ 4.2 を参照してください
• バージョンの選定では破壊可能性を考慮します — 複数のバージョンで脆弱性を修正できる場合は、最も低いバージョン番号ではなく、破壊可能性のリスクが最も低いものを優先します
• 修正方法がない場合は修正を試みません — ステップ 2.5 を参照してください

バッチモードの追加要件：開始前にユーザーの計画承認が必要です。脆弱性は最大 20 件、ファイルは最大 15 個です。次に進む前に各修正を検証します。部分的な成功も認められます（ユーザーから別途要望がない限り）。バッチ修正はすべて 1 つの PR にまとめます。

---

完了チェックリスト

単一モード：脆弱性を文書化 → SCA の修正方法を検証（または修正不可レポート）→ SCA の修復戦略を決定（A／B／C）→ SCA の破壊的変更を評価 → 修正を適用（または完全なアドバイザリー）→ 再スキャンで問題がないことを確認 → テストに合格 → 概要を表示 → Snyk へのフィードバックを送信 → PR を作成するか確認（修正を適用した場合）→ 確認された場合は PR を作成。

バッチモード：完全なスキャンを実行 → 計画を表示して承認を得る → すべての項目を試行 → 各修正を検証 → 結果を追跡 → バッチの概要を表示 → Snyk へのフィードバックを送信 → PR を作成するか確認 → 確認された場合は単一の PR を作成。