GitHubは2026年10月13日、撤回済みのDependabotアラートを見分けやすくする変更を発表しました。脆弱性アラートの通知に撤回を知らせるイベントが加わり、APIでも撤回済みかどうかを区別できるようになります。通知を社内の管理システムに取り込んでいる会社は、受信処理と応答コードの扱いを確認する必要があります。
撤回通知には、削除前のアラート情報も含む
GitHubによると、元の勧告や脆弱性が無効になると、該当するアラートを撤回・削除します。今回、その撤回を外部の連携先でも検出できるようにしました。
変更の一つは、イベント発生時に外部へ通知する仕組み「Webhook」です。dependabot_alertのイベントに、撤回を示すwithdrawnアクションが追加されました。このイベントを既に購読している連携先には、撤回イベントも自動配信されます。
通知データには、削除前のアラート番号、脆弱性情報を識別するGHSA・CVE IDが含まれます。さらに、対象パッケージと、依存関係を記したマニフェストのパスも含みます。連携先では、これらを手掛かりに、自社で保存したアラートや対応記録との照合を検討できます。
注意したいのは、撤回の理由が「元の勧告や脆弱性が無効になったこと」だという点です。社内の記録では、修正版への更新による対応完了と、勧告の撤回を混同しない扱いにするのがよいでしょう。
REST APIは404ではなく410を返す
外部プログラムからアラートを取得・更新するREST APIも変わります。撤回済みアラートに対する応答は、404 Not Foundではなく410 Goneになります。GitHubによると、これにより撤回済みのアラートと、元から存在しないアラートを区別できます。
取得失敗をすべて同じエラーとして扱っている連携では、この違いを記録や処理に反映できるか確認したいところです。たとえば、撤回されたアラートを対応待ちのまま残さないよう、APIの応答と社内の管理記録を照合する運用が考えられます。
変更はgithub.comの全リポジトリで利用可能です。GitHub Enterprise Server 3.24にも含める予定ですが、こちらは予定として発表されています。
影響する会社・しない会社
- 影響する:
dependabot_alertのWebhookを購読し、通知を社内システムや対応記録へ取り込む会社です。既存購読者にも撤回イベントが自動配信されるため、withdrawnを受けた際の処理を確認する対象になります。
- 影響する: REST APIでDependabotアラートを取得・更新する会社です。撤回済みアラートに対する
410 Goneを、元から存在しないアラートと区別して扱うか判断する必要があります。
- 影響する: GitHub Enterprise Serverを使う会社は、3.24への導入を検討する際の確認事項になります。変更は同版に含める予定で、今回の発表だけで導入済みと判断しないようにします。
- 影響しない: 上記WebhookとREST APIによる連携を使っていない会社は、その連携処理の改修対象ではありません。ただし、github.comの変更対象は全リポジトリであり、リポジトリ自体が対象外という意味ではありません。
情シスが今日やること
以下は社内で進める確認手順です。GitHubが対応期限を指定したものではありません。
- 今日、開発担当または連携システムの管理担当に、
dependabot_alertのWebhook購読とREST APIによる取得・更新の有無を確認します。連携先の一覧と管理担当者を整理してください。
- Webhookを使っている場合は、受信側のイベント振り分け処理を確認します。
withdrawnをどう扱うか、アラート番号、GHSA・CVE ID、パッケージ、マニフェストのパスで既存記録と照合できるかを点検します。
- REST APIを使っている場合は、次回の連携処理の変更前に、取得・更新時のエラー処理を確認します。
410 Goneを記録できるか、404 Not Foundと区別する必要があるかを開発担当と決めます。
- 脆弱性管理の担当者に、撤回と修正完了を分けて記録する方針を知らせます。GitHub Enterprise Serverを使っている場合は、3.24への導入検討時に今回の変更を確認項目へ加えます。
