Dependabot APIのバージョン項目：記録値と実際のデプロイを分ける
GitHubは2026年10月20日、DependabotアラートのREST応答にdependency.version_requirementを追加した。調査の手掛かりは増えるが、現在の本番環境にインストールされた正確なバージョンの証明にはならない。公式の機能説明とチーム向けの運用提案を分けて読む。
脆弱な範囲とリポジトリの記録は別の列
既存のvulnerable_version_rangeはアドバイザリが対象とする範囲だ。新項目はDependabotが最後に記録したバージョンまたは制約を示す。パッケージ、エコシステム、manifest_pathとともに両方を保存する。制約を単一の導入済みバージョンとして並べ替えず、表示名も「記録されたバージョン／条件」とする方が誤解を減らせる。
検出経路で値の意味が変わる
lockfileなら解決済みバージョン、lockfileのないmanifestなら宣言されたバージョンや制約、dependency submission APIならビルドツールが送った解決済みバージョンだ。単一アラート、リポジトリ・組織・企業の一覧、dependabot_alert webhookに含まれる。github.comとデータ所在地対応Enterprise Cloudで利用でき、Enterprise Server 3.24にも含まれる予定だ。旧Serverでの対応を推測しない。
nullと部分的な記録を通常の入力として扱う
値がなければnull。複数の脆弱なバージョンを含むアラートでは一つの記録値が全体を表さない場合があり、長い制約は切り詰められることもある。運用案として文字列とnullを保持し、不明を安全と読み替えず、過去のチケットの欠損も明示する。アラート件数が一致してもバージョン情報の完全性は証明できない。
代表的なアラートで連携を検証する
秘密を除いた応答、取得時刻、アラート番号、manifestの場所を一緒に残す。lockfile、manifest制約、nullの例をチケット画面まで追い、意味が保たれるか確認する。webhookと一覧を併用するならリポジトリとアラートIDを照合し、重複を防ぐ。権限は各エンドポイントの文書で確認する。これは運用提案であり、自動修正の新機能ではない。
現在のデプロイを知るにはビルド・配布記録を別に確認する。更新後は既存テストとアラート状態を再確認する。追加項目が調査を短縮しても、リリース検証まで削除する理由にはならない。担当者が制約、不明、代表的な記録値を区別し、次に必要な証拠を判断できることを完了条件にしよう。
公式情報
GitHub Changelog · Dependency versions
GitHub Docs · Dependabot alerts REST API
2026年10月21日確認。アラート応答一件とセキュリティチケットのバージョン表示を比べてみよう。