Dependabotの警告だけでは漏れる｜PR前後で分ける依存関係検査

Dependabot Alertsを有効にしても、脆弱な依存関係を持ち込むPRが自動的に止まるわけではない。GitHubのDependabot Alertsの説明では、検査対象は既定ブランチで、新しい脆弱性がGitHub Advisory Databaseに追加されたとき、または依存関係グラフが変わったときに警告するとされている。

マージ前の役割を担うのはDependency Reviewだ。GitHubのDependency Reviewの説明によると、PRで追加・更新される依存関係と既知の脆弱性を確認できる。Dependency Review Actionのチェックが失敗した場合、そのチェックを必須に設定していればマージを止められる。つまり、既定ブランチに残る問題の調査と、PRで入る問題の阻止を別々に設定する必要がある。

監視とゲートを同じ工程に置く

開発の流れには、変更が入る前の判定と、既定ブランチに入った後の監視という異なる仕事がある。PRでは新しく加わる依存関係の差分を調べ、問題があれば修正してからマージする。マージ後に脆弱性情報が公表された場合は、既定ブランチの警告を起点に調査する。PR時点でチェックが成功していても、将来の警告まで不要になるわけではない。

開発者が依存関係を変更したら、PRのDependency Reviewで追加・更新されたパッケージとチェック結果を見る。
必須チェックが失敗したら、開発者が安全なバージョンや別の依存関係を検討し、修正後にチェックを再実行する。
マージ後にDependabot Alertが出たら、警告の一次担当が影響範囲と修正版の有無を調べ、修正担当を決める。
対応不要という判断は、根拠を残して警告またはPR側の例外として扱う。

この分担は、担当者の少ないチームでも組める。警告の一次担当とPRのレビュー担当を決め、修正を行う人は案件ごとに割り当てればよい。通知を受け取る人数を増やすことより、未解決の警告と止まったPRのそれぞれに次の担当者がいることを優先する。

既定ブランチの警告を調査につなぐ

Dependabot Alertsを有効にすると、既定ブランチの依存関係グラフを使って既知の脆弱性が調べられる。警告には影響を受けるファイル、深刻度、修正版がある場合はその情報が示される。一次担当は通知だけに頼らず、リポジトリの未解決警告も確認し、対象パッケージがどこから入ったかを調べる。直接追加した依存関係と、別のパッケージを通じて入った依存関係では、修正する場所が異なり得る。

通知の仕組みには見落としやすい条件がある。GitHubの標準設定では、書き込み権限などを持つだけで全員にメールが届くわけではなく、リポジトリのウォッチとセキュリティ警告の通知設定も関係する。また、機能を最初に有効化した際に見つかった既存の脆弱性については、そのすべてを新着通知として送る仕様ではない。導入時に警告一覧を確認する作業は、後から届くメールの確認とは分けておく。

通知が多い場合は、受信者を無制限に増やす前に、誰が警告を仕分けるか決める。一次担当が対象と修正版を確認し、対応が必要なものを修正担当に渡す。警告を閉じる時点は「通知を見たとき」ではなく、修正が既定ブランチへ入ったか、対応不要の判断を記録したときだ。これなら、メールの既読状態と脆弱性への対応状況を混同しにくい。

PRの失敗をマージ阻止につなぐ

GitHubのPRで追加した依存関係がDependency Reviewの必須チェックに失敗し、マージが止まる

PRの「Files changed」で依存関係の差分が見えることと、マージが止まることは別の設定だ。まずリポジトリで依存関係グラフを利用できる状態にし、PRでDependency Review Actionが走るワークフローを用意する。そのうえで対象ブランチのルールにチェックの成功を必須条件として登録する。Actionが脆弱な依存関係を検出して失敗しても、必須チェックでなければ失敗だけでマージを阻止する設定にはならない。

レビューでは、マニフェストに書かれた直接依存だけで判断しない。一つのパッケージを更新した結果、ロックファイル中の間接依存関係も変わることがある。Dependency Reviewは追加、削除、更新された依存関係と、ロックファイルに現れる間接依存の変更を示す。チェックの成否に加え、どのバージョンが新たに入るのかを見ると、修正PRが別の既知の問題を持ち込む場合にも気づける。

Actionは、どの深刻度でチェックを失敗させるか設定できる。チームはマージ前に必ず解消する範囲を決め、その設定をレビュー担当と共有する必要がある。深刻度の基準を設けても、低い深刻度の警告や既定ブランチで後から判明した問題の調査は、Alerts側の仕事として残る。利用可能なリポジトリの種類や有料機能の条件もあるため、対象リポジトリでDependency Reviewを使えるかを設定前に確認する。

自動更新PRも通常の変更として扱う

依存関係の更新PRを自動作成する運用でも、マージ前の判定は省かない。更新PRは既定ブランチの警告を解消する候補になり得るが、提案された変更を受け入れるかはPRの差分とチェック結果で判断する。修正対象のパッケージだけでなく、同時に変わるロックファイルと間接依存関係も確認する。

自動更新を採用するかどうかと、警告を誰が処理するかも別の判断だ。更新PRが作られていても、必須チェックの失敗や競合でマージできなければ、既定ブランチの問題は残る。一次担当は警告と修正PRを対応付け、PRの担当者が変更を直せる状態にする。これにより、提案が作られたことを対応完了と取り違えずに済む。

却下には判断の理由を残す

警告の却下と、PRのチェックに設ける例外は、影響する場所が違う。GOV.UKのセキュリティ警告運用指針では、対応不要と判断した警告について理由と説明を記録する。同組織のDependency Review運用では、特定の脆弱性を例外にする場合、GHSA識別子を設定に加え、コードのコメントに理由を残す。後者は共有ワークフローにも影響するため、まれな例外として扱う方針だ。

少人数のチームでも、判断する人、対象の依存関係、理由、見直す条件を短く残せる。たとえば条件付きの判断として「問題のある機能を利用していない」とするなら、どの利用経路を調べたかも記録する。後で利用方法が変わったとき、以前の判断をそのまま引き継いでよいかを確かめられる。

PR側で脆弱性の識別子を許可する設定は、後続の変更にも適用され得る。例外を加えるレビューでは、その識別子が指す問題、許可する理由、解除する条件を確認する。既定ブランチの警告を却下する操作とPRの必須チェックは独立しているため、片方の判断がもう片方へ自動的に反映される前提で運用しない。