Dependabotの警告が多いなら、脆弱な関数への経路を見てみよう
同じパッケージの警告でも、修正の優先度は同じとは限りません。リクエスト処理で脆弱な関数を呼ぶサービスと、インストール済みでもその関数を使わないサービスでは事情が違います。2026年10月28日に公開されたDependabotの到達可能性分析プレビューは、この違いを見せてくれます。
パッケージ一覧から呼び出し経路へ
Dependabotが脆弱な依存バージョンを特定するのに対し、新分析はリポジトリのコードから対象関数への経路を探します。GitHub管理のActionsワークフローでCodeQLが呼び出しグラフを作り、対象関数を特定する整理済みアドバイザリーデータと照合します。
図は説明用の架空コードです。注文APIはヘルパーを通じてpackage.parseUnsafeを呼びます。別の入口はpackage.formatLabelだけを使い、このグラフでは対象に到達しません。実在する脆弱性やGitHubの実行結果ではなく、パッケージ名だけでは判断しきれない理由を示しています。
4つの判定を読み分ける
Reachableは少なくとも1つ経路が見つかった意味で、攻撃成功の証明ではありません。外部入力や本番での利用も関係します。表示される最大5つのサンプル経路も全経路の一覧ではありません。
Potentially reachableは呼び出しを否定できず、Reachableとともに優先対応します。Unreachableは分析完了後に経路が見つからなかった状態、Reachability unavailableは判定を提供できなかった状態です。同じ安心材料にはできません。どの判定も警告を自動で閉じたり無視したりしません。
コード変更直後に判定は変わらない
有効化で初回スキャンが始まり、警告が開いている間は24時間ごとに再分析します。pushで即座に始まるわけではなく、プレビュー中は任意の時点で実行できません。
今日呼び出しを削除しても古いReachableが残ることがあります。新しく追加しても以前のUnreachableが一時的に見える場合があります。2枚目は架空グラフをPythonで探索した実際の出力です。本当の修正では、完了したスキャン時刻と分析対象コードを対応させて読みたいところです。
利用できるリポジトリ
対象はデータレジデンシーを含むGitHub Enterprise Cloudです。JavaScript・TypeScript、npm・Yarn・pnpmのlockfile、有効なDependabot alertsが必要です。GitHub Code Securityライセンスは不要で、プレビュー分析は無料、Actionsの課金分数も消費しません。セルフホストランナーは未対応です。
初期状態では無効です。Settings > Advanced Securityや組織・企業のカスタムセキュリティ構成から有効化できます。大きなモノレポなどでは3時間やリソースの制限でunavailableになる場合があります。深刻度、EPSS、本番の露出と組み合わせることで、開いた警告の対応順をより具体的に考えられます。