今回の変更：警告が消えた理由を追いやすくする

GitHubは2026年10月13日、撤回されたDependabot警告の識別改善を発表しました。警告の根拠となったアドバイザリや脆弱性が有効ではなくなると、その警告を撤回して取り除く仕組みに関する変更です。

公式発表で確認できた点は次のとおりです。

  • dependabot_alert Webhookに withdrawn actionを追加。削除前の警告番号、GHSA・CVE識別子、パッケージ、マニフェストのパスを通知に含めます。
  • このイベントの既存購読者にも新しい通知を配信します。ただし、受信側が新しいactionを正しく扱えるかは別の確認です。
  • 撤回済み警告をREST APIで取得・更新すると、従来の404ではなく 410 Gone を返します。
  • 発表上、GitHub.comの全リポジトリが対象です。GitHub Enterprise Serverへの収録は3.24とされています。

公式資料確認のみで、当サイトによる通知受信・API応答の実機検証ではありません。 10月14日に確認したREST資料には取得・更新の410が載っています。一方、確認できたWebhook資料の本文ではwithdrawnの詳細を見つけられなかったため、その通知内容は上記の公式発表に基づきます。資料の反映状況と実環境での動作を同一視しません。

撤回・修正・却下は何が違う？

当サイトの整理では、点検時に次の三つを分けると、対応の取り違えを減らせます。

  • 撤回：警告の根拠が有効ではなくなったという扱い。自分がパッケージを更新した証拠にはなりません。
  • 修正済み（fixed）：警告の状態としての修正。変更した依存関係と、実際に公開・稼働している成果物の対応は別に確認します。
  • 却下（dismissed）：理由を付けて警告を閉じる扱い。リスクを許容した場合などもあり、修正版の導入と同じ意味ではありません。

REST資料は警告の状態にopen、fixed、dismissed、auto_dismissedを挙げ、却下に理由を求めています。withdrawnをこれらと同列の一覧フィルターとして使えるとは、今回の確認では説明できません。

たとえるなら、点検票が「判定の訂正で取り下げられた」「部品を交換した」「理由を記録して対応を見送った」では、残すべき記録が違います。これは理解のための例で、GitHubの内部実装を示すものではありません。

警告が減ったら、この順番で確認する

以下は当サイトが提案する読み取り中心の点検手順です。画面名は利用環境で異なることがあり、新機能の操作実証ではありません。

  1. 同じ対象か確認する：リポジトリ、警告番号、パッケージ、対象ファイルを照合する。表示フィルターや閲覧権限の違いも確認する。
  2. 状態と根拠を分ける：固定された警告の記録、公式アドバイザリ、利用できる通知から、撤回・修正・却下のどれかを確かめる。見つからなければ「未確認」とする。
  3. 更新したなら差分を確認する：マニフェストやロックファイルの版、更新したコミット、テスト結果を対応付ける。更新PRが開いただけ、マージしただけでは本番適用済みにしない。
  4. 本番を照合する：ビルド・デプロイの対象コミットと、実際に稼働する版・成果物を確認する。GitHubの既定ブランチと本番が常に一致すると推定しない。
  5. 残る対応を記録する：他の警告、公式の更新推奨、未確認の稼働版などを残し、確認担当と次の作業を決める。

Dependabotの公式説明によれば、検出は既定ブランチを対象とし、すべてのセキュリティ問題を捉えられるわけではありません。警告0件は、安全証明書ではありません。 対応の優先順位は脆弱性の更新点検と合わせて考えます。

外部の監視ツールと連携している場合

当サイトの運用上の評価として、新しい通知は「なぜ台帳から警告が消えたか」を説明する材料になります。ただし、既存の受信処理が未知のactionを無視したり、一律に「修正完了」へ変換したりすると、記録の意味が失われます。

  • withdrawnを修正済みとは別の終了理由として扱えるか、承認済みの検証環境で確認する。
  • 必要な識別子と受信時刻を、組織の保存方針に従って記録する。本文全体を公開ログへ転載せず、秘密値や個人情報を除く。
  • 410は、今回のDependabot警告取得・更新エンドポイントでの意味として扱う。他のAPIの410まで同じ意味にしない。
  • 404、403、通信失敗を撤回と決めつけない。対象・権限・障害の切り分けを先に行う。

この記事を読むために、新しいトークンを作ったり、権限を広げたりする必要はありません。連携を変更する場合は担当者が対象・権限・検証・戻し方を確認してください。今回、当サイトのWebhookやセキュリティ設定は変更していません。

架空例：ライブラリAの警告が一覧から消えた

小さな予約サイトでライブラリAの警告が消えましたが、担当者は更新作業をしていません。ここで「修正した」と報告すると、更新履歴と説明が食い違います。

公式の撤回通知と識別子が一致したなら、「この警告は撤回された。パッケージの版は変更していない」と記録します。別の弱点や、通常の保守更新が不要になったとまでは判断しません。通知や根拠が確認できなければ、一覧から見えない理由は未確認のまま調べます。

見本の記録は「対象ファイル／警告の識別子／確認した状態と根拠／依存関係を変更したか／本番の適用状況／残る確認事項」です。実アカウントや顧客情報は公開用の例に使いません。

便利になる点と、残る限界

当サイトの評価として、今回の改善は警告の終了理由を外部の台帳と整合させる助けになります。件数だけを追うより、説明可能な点検へ近づける点が有用です。

一方、過去の撤回への遡及通知、読者の受信処理、実際の本番稼働版は今回未確認です。通知を受け取れない環境で、撤回の事実を推測で埋めてはいけません。まず確認できる証拠を整理し、ログ点検の基本と合わせて、確認済みと未確認を分けて残します。