Dependabotを支える技術：GitHub脆弱性対応の「高速ルート」「低速ルート」
公開日
現代のソフトウェア開発において、npm audit や Dependabot のような自動化ツールからの通知は、開発者にとって日常的なものとなりました。しかし、「修正パッチが出ているのに、なぜDependabotからの通知が遅いことがあるのか？」と疑問に思ったことはないでしょうか。実は、その裏側にあるデータベースの更新プロセスには、情報の「通り道」によって劇的な速度差が存在します。
本記事では、Claudio Segal氏らが著した研究論文「Characterizing and Modeling the GitHub Security Advisories Review Pipeline」に基づき、Dependabotの頭脳であるGitHub Security Advisories（GHSA）の実態を解説します。
Dependabotを支える裏側：GHSAの全体像と役割
Dependabotがアラートを出すためには、その根拠となるデータが必要です。そのデータベースが「GitHub Security Advisories（GHSA）」です。GHSAには、GitHubによって内容が確認された「レビュー済み」のアドバイザリと、未確認の「未レビュー」のものが存在します。2025年8月時点のデータでは、全288,604件のうち、レビュー済みはわずか23,563件（約8.2%）でした。
このレビュープロセスは自動化だけでなく、多くの「人」の手によって支えられています。論文では、アドバイザリ作成に関与したユーザーの役割を分析しています。
図表1：GitHub Security Advisoriesで確認された役割と頻度(抜粋)
| 役割 (Role) | 出現回数 | 説明 |
|---|---|---|
| Analyst | 5,610 | 脆弱性の正確性や深刻度を検証・確認する。 |
| Reporter | 2,086 | ベンダーや責任者に脆弱性を通知する。 |
| Finder | 616 | 脆弱性を発見する。 |
| Remediation Developer | 602 | コードの修正や対策案を作成する。 |
| Remediation Reviewer | 349 | 修正の有効性と完全性をレビューする。 |
| Coordinator | 236 | 対応プロセスの調整を行う。 |
このデータから、Dependabotの通知の背後には「Analyst」と「Reporter」の存在が大きく関わっていることがわかります。発見と報告に多くのリソースが割かれている一方で、修正コードを書く「Developer」や確認する「Reviewer」の記録は比較的少なく、発見から報告までのプロセスがいかに重要であるかが伺えます。
情報の「鮮度」を決める2つの主要ルート
Dependabotが参照する「レビュー済みアドバイザリ」はどこから来るのでしょうか。主な情報源は2つあります。ここが、通知速度を分ける重要な分岐点です。
- NVD（National Vulnerability Database）： 世界的な脆弱性データベース。
- GRA（GitHub Repository Advisories）： GitHub上でリポジトリ管理者が直接報告する機能。
以下の図は、アドバイザリがどのプラットフォームを経由してGHSAに登録されるかという「情報の流れ」を示したものです。
図表2：プラットフォーム間のアドバイザリ情報の流れ
左側のGRAやNVDから、右側のGHSAへ情報がどのように流れるかを帯の太さで表しています。
この図が示す重要な事実は、情報の流入経路が大きく2つに分かれているということです。
- GRAルート： 開発者がGitHub上で直接アドバイザリを作成し（GRA）、それがGHSAに取り込まれる経路（青い帯）。
- NVDルート： NVDで公開された情報が、その後GHSAにインポートされる経路（緑の帯）。
論文によると、レビュー済みアドバイザリの約67.2%がNVD由来である一方、GRA由来は26.4%に留まります。しかし、この「由来」の違いが、Dependabotの通知タイミングに決定的な差を生んでいます。
自動化で高速化したNVD
GitHubは2022年6月頃にNVDからのデータ取り込みプロセスを自動化・強化しました。その効果は以下のグラフにはっきりと表れています。
図表3：アドバイザリ公開月ごとのレビュー期間の中央値
オレンジ色の線がNVD由来、青色の線がGRA由来のレビュー所要日数を示しています。
グラフの右側をご覧ください。自動化以前は大きく遅延していたNVD由来のアドバイザリですが、2022年6月以降は劇的に改善し、GRAと同じくほぼゼロに近い位置で推移しています。これは、「一度データベースに取り込まれてしまえば」、NVD由来であってもGRAと同様に素早くレビュー処理が行われていることを示しています。
パッチ公開から通知までの「空白期間」
開発者にとって最も恐ろしいのは、「修正パッチは公開されているのに、Dependabotから通知が来ない」という状況です。この空白期間が長ければ長いほど、システムは既知の脆弱性に無防備な状態でさらされることになります。
以下の表は、2022年6月以降のデータにおける「パッチ公開からGHSAレビュー完了までの日数」を比較したものです。
図表4：パッチ公開からレビューまでの所要日数（2022年6月以降）
| 情報源 (Source) | 25パーセンタイル | 中央値 (50th) | 75パーセンタイル | 90パーセンタイル |
|---|---|---|---|---|
| GRA（高速ルート） | 0.51日 | 2.04日 | 12.18日 | 78.99日 |
| NVD（低速ルート） | 7.06日 | 27.69日 | 127.23日 | 672.7日 |
結果は衝撃的です。 GRA経由の場合、パッチ公開から約2日（中央値）でレビューが完了し、Dependabotが通知を出せる状態になります。 対照的に、NVD経由の場合は約28日もの時間を要しています。
この「約1ヶ月の遅れ」は、セキュリティ対策において致命的なリスクになり得ます。攻撃者はパッチが公開された時点で脆弱性の詳細を解析し、攻撃コードを作成することが可能です。もしあなたのプロジェクトがNVD経由の情報（従来のCVE申請ルートのみ）に依存している場合、攻撃者に対して約1ヶ月ものハンディキャップを負うことになるのです。
結論
本研究が明らかにしたのは、Dependabotの通知速度には明確な「二極化」が存在するという事実です。
GitHubのリポジトリ機能（GRA）を使って直接報告された脆弱性は、極めて迅速にレビューされ、エコシステム全体に通知されます。一方で、NVDを経由する従来のルートは、自動化が進んだ現在でも数週間の遅延が発生する傾向にあります。
オープンソースのメンテナや利用者にとって重要なのは、この「経路による速度差」を理解しておくことです。GRA経由の報告は、NVDを経由するプロセスと比較して、Dependabotなどのツールがユーザーに警告を届けるまでの時間を大幅に短縮する傾向があります。どのルートで情報を開示するかという選択が、エコシステム全体への周知スピードに直結しているという事実は、脆弱性対応を考える上で無視できない要素と言えるでしょう。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料: