2026年5月、GitHub Advisory Databaseは1,560件のレビュー済みadvisoryを公開しました。これは通常の月間公開件数の5倍以上で、過去最高を記録しました。

それでも、処理が追いつきませんでした。

ここ数ヶ月で、脆弱性エコシステムは根本的に変化しました。非公開脆弱性レポート、リポジトリアドバイザリ、CVEリクエストが同時に増加し、システム全体が新しい運用規模に移行しています。

このブログは、脆弱性報告の変化やPVRおよびAdvisory Databaseのロードマップ開発を追跡するGitHubコミュニティの継続的な議論に基づいています。このスレッドで繰り返し指摘されているのは、プラットフォーム変更がadvisoryのキュレーションやデータ品質に与える下流への影響です。これは、脆弱性報告における品質と責任共有を重視するGitHubの広範な方針転換とも一致しており、それがadvisoryデータのキュレーションとメンテナンスの方法に直接影響しています。

TL;DR

新しいadvisoryのレビュー時間が長くなっている理由は、脆弱性の件数と複雑さが大幅に増加したためです。advisoryの品質は変わっていません。レビュー済みadvisoryは引き続き人間による検証が行われており、既存のalertは通常どおり機能します。ご協力いただける場合は、次の3点に焦点を当ててください：完全な脆弱性データを提出する、メンテナと研究者と緊密に連携する、公開の明確な意図がある場合にのみCVEをリクエストする。

過去最高の出力と前例のない入力

5月は一時的な急増ではありませんでした。3月から5月にかけて、毎月6,000件を超えるadvisory判断を継続的に行いました。これには既存advisoryの更新、新規advisoryの公開、受信advisoryのレビューが含まれ、過去の3ヶ月間のピークを上回りました。

同時に、あらゆるソースからの流入が加速しました：

  • プラットフォーム全体のPrivate vulnerability reportsが、1月の週あたり約550件から5月の大半で3,000件超/週に増加しました。
  • Repository advisoriesが週あたり約650件から5,000件超/週に拡大しました。
  • GitHub CNAのCVEリクエストは5月だけでほぼ4,000件に達し、前年比で約10倍になりました。
  • CVEプログラムは2026年だけですでに30,000件超のCVEを公開しています。
  • 170万件以上のリポジトリがPrivate vulnerability reportingを有効にしています。
Line graph showing a sharp increase in PVR submissions, CNA requests, and Repo GHSAs published, starting around January 2026. The lines go back to May 2025 and is relatively flat with a slight increase until January 2026.

これは局所的な急増ではありません。脆弱性開示エコシステム全体における構造的な変化を反映しています。

影響

この急増により、4月中旬以降、内部の公開目標を一貫して達成できていません。処理時間は当初約1週間、その後、かなりの割合で数週間に延びています。公開時間の長期化は露出期間を長くする可能性があります。私たちはこれを真剣に受け止めており、タイムリネスは本データベースが提供する価値の中核をなすものです。

引き続き機能している点

データパイプラインと公開インフラストラクチャは、この期間を通じて継続して稼働しています。インポートは実行されており、データの整合性は保たれ、公開済みadvisoryは正確です。本日レビュー済みステータスに到達したadvisoryは、以前と同じ品質基準を満たしています。

CVE割り当ての品質は引き続き高い水準を維持しています。割り当て率は急増期間を通じて91–94%で推移しており、過去の基準と同等かそれ以上であり、受領したリクエストの品質に明確な低下が見られないことを示しています。

問題はスループットです。advisoryデータを検証・補強・公開するシステムは機能していますが、設計された量と複雑さを上回る規模で運用されています。

作業の均一性について

すべてのセキュリティadvisoryが同じレベルの労力を必要とするわけではありません。適切にフォーマットされたadvisoryもあります。advisoryの詳細に影響を受けるパッケージと関連するエコシステムが明確に記載され、バージョン範囲が文書化されており、修正がタグ付けされている場合、キュレーターは数分で検証・公開できます。

しかし、受信advisoryの増加する割合で、より多くの調査が必要になっています：

  • パッケージの曖昧性解消。 advisoryの詳細に「foo」と記載されていても、それがnpm上のfooなのか、PyPI上のpython-fooなのか、Maven上の無関係なfooなのかが不明な場合があります。上流データにエコシステムが指定されていない場合、キュレーターが特定します。
  • バージョン範囲の再構築。 多くのセキュリティadvisoryに影響を受けるバージョン範囲が記載されていない、または実際のリリース履歴と一致しない範囲が記載されています。キュレーターはコミット、変更履歴、タグを追跡して、実際に影響を受ける範囲を特定します。
  • 複数エコシステムのadvisory. 一部のプロジェクトは複数のレジストリにパッケージを提供しています。たとえば、同じ機能の.NET実装（NuGet）とJavaScript実装（npm）の両方を持つライブラリの場合、共有ロジックの脆弱性が両方に影響します。これには複数のデータソースにわたる独立した検証が必要です。
  • 上流データの矛盾。 CVEレコード、メンテナのadvisory、コミット履歴の間で影響範囲について矛盾がある場合、誰かが真実を判断する必要があります。

歴史的には比較的シンプルなadvisoryが主流で、難しいものは吸収可能でした。量が急増すると、キューには両方が溜まり、複雑なものは不均衡に時間がかかるため、複合的な影響が生じます。構成の割合がこれまで以上に重要になっています。これは単に作業量が増えるだけでなく、複雑さも大幅に増しているということです。

「reviewed」の実際の意味

レビュー済みadvisoryは単に再公開されたレコードではなく、検証の結果です。

キュレーターは次の作業を行います：

  • 脆弱性を正しいエコシステムのパッケージにマッピングする
  • リリース履歴に対して影響を受けるバージョンと修正バージョンを検証する
  • 上流データの正確性を確認する
  • 重複と一貫性をチェックする
  • 分類とスコアリングを検証する

これにより、下流のツールは追加の検証なしにデータを利用できます。

検証を省略して公開を早めることは、大規模な誤検知を増加させ、遅延よりも大きなリスクを生む可能性があります。

より広範なエコシステムの変化

この傾向はGitHubを超えて広がっています。

報告・公開される脆弱性の量は急速に増加しており、エコシステム全体の組織がこの変化に対応しています。

システムは設計どおりに機能しています。脆弱性の報告・開示・追跡がこれまで以上に多く行われています。これにより、advisoryのキュレーションを含め、下流に圧力がかかっています。

現在取り組んでいること

  • コミュニティ投稿の品質とスループットの改善。 コミュニティ投稿はAdvisory Databaseの改善に重要な役割を果たしており、いずれも他のadvisoryと同等の検証基準でレビューされます。トリアージと優先順位付けを強化し、高品質な投稿を早期に特定し、一貫してレビューし、キューをより速く通過させています。これにより、現在の量に対応しつつ、高品質で信頼できるデータセットを維持するという主要な目標を強化しています。
  • キュレーションを支えるシステムのスケーリング。 バックエンドのキュレーションシステムの容量を拡大し、より高い持続的スループットに対応できるようにし、分析とキュー管理を支えるデータインフラストラクチャの近代化を継続しています。
  • AI支援の調査ツールの構築。 キュレーターがadvisoryレビューの調査段階でAIを活用した支援を受けられるツールを開発・導入しました。最終的な判断はキュレーターが行いますが、ルーチンな調査をより速く完了できるようになり、高品質なadvisoryの処理が加速しています。
  • 最も効果的な領域での自動化の拡大。 上流のCVE情報からより多くのデータを抽出する自動化や、コミュニティ投稿と既にレビュー済みのadvisoryの連携処理を改善しました。これにより、判断ごとの時間を短縮しつつ、品質基準を維持しています。
  • ドキュメントとトレーニングへの投資。 運用ドキュメントを大幅に拡充しました。これにより、新しいチームメンバーのオンボーディングを迅速化し、チーム全体の整合性を向上させています。

次に構築すること

この新しい規模を支えるため、次の分野に投資しています：

  • 最も一般的なケースのadvisoryあたりの時間の削減。 受信advisoryの大部分は、正しいパッケージの特定、バージョン範囲の確認、修正の有無のチェックなど、予測可能なパターンに従う調査を必要とします。これらのパターンを加速するツールに投資し、キュレーターが真に曖昧なケースに人間の判断を集中できるようにします。
  • リスクベースのレビュー優先順位付けのスマート化。 パッケージの使用状況、積極的な悪用の証拠、エコシステムへの影響などのリスクシグナルを追加で優先順位付けに活用し、最も重要なadvisoryを最初にユーザーに届けることを目指しています。
  • 上流データソースとのフィードバックループの改善。 キュレーション時間の多くが、不完全または不正確な上流データの修正に費やされています。取り込み元のソース、特にリポジトリのGitHub Security AdvisoryおよびPrivate Vulnerability Reportingのデータ検証を強化し、データ品質の問題をレビューキューではなく発生源に近い場所で解決できるようにします。
  • 透明性の継続。 進捗状況を随時共有します。改善が見られればお知らせし、新たな課題が発生した場合も共有します。

ユーザーへの影響

  • Dependabotユーザー： 既存のalertは影響を受けません。新しいadvisoryのトリガーが遅くなる可能性がありますが、重大な問題は優先されます。
  • APIおよびフィードの利用者： レビュー済みデータは引き続き正確です。未レビューのadvisoryは表示されますが、まだ検証されていません。
  • メンテナ： リポジトリアドバイザリは引き続きグローバルデータベースに流れ込みます。優先順位付けは、プロジェクトの影響度や重大度など複数の要因に基づいて行われます。

ご協力のお願い

脆弱性レポートに完全なデータを含めてください。 影響を受けるバージョン範囲、根本原因、明確な再現手順を提供することは、advisoryのレビュー速度と精度に直接影響します。このデータが完全であれば、キュレーションは数分で完了します。不完全な場合は、キュレーターがソースコード、リリース履歴、矛盾する上流シグナルから不足する詳細を再構築する必要があります。この規模では、そうしたギャップが急速に複合します。高品質な上流データは、エコシステム全体の速度と精度を向上させる最も効果的な方法のひとつです。

適切なadvisoryの詳細を含めてください。 エコシステムのカテゴリ化、パッケージ名、バージョン範囲のフォーマットについてはベストプラクティスガイドを参照してくださいが、いくつかの追加の詳細が、advisoryのレビューとGitHub Advisory Databaseへの公開の速度と精度に直接影響します。

  • レジストリに表示されている通りのパッケージ名を使用してください。 advisoryのパッケージ名はリポジトリ名やプロジェクト名ではなく、レジストリ名と一致させる必要があります。下流のシステムはレジストリ識別子を使用してadvisoryを影響を受ける依存関係と照合します。名前が誤っていたり欠落していると、alertを確実に生成できず、影響を受けるユーザーに通知されない可能性があります。レジストリ名を使用することで、advisoryを正しくリンク・索引付け・配信できます。
  • 影響を受けるすべてのパッケージをリストしてください。 一部の脆弱性はプロジェクト内の複数のパッケージに影響します。各影響を受けるパッケージは、それぞれのエコシステム、パッケージ名、バージョン範囲を指定して個別にリストする必要があります。advisoryはパッケージレベルで消費されるため、パッケージの欠落はそれに依存するユーザーの欠落を意味します。影響を受けるすべての既知のパッケージを含めることで、カバレッジが向上し、影響を受けるすべてのユーザーにalertが届くようになります。
  • 完全なCVSSベクトル文字列を提供してください。 GitHub Advisory DatabaseはCVSS 3.1および4.0をサポートしています。「High」などの重大度ラベルは簡易的な要約ですが、完全なCVSSベクトル文字列には攻撃の複雑さ、必要な権限、ユーザー操作などのより豊富な属性が含まれており、脆弱性をより詳細に記述します。この構造化された情報により、重大度を検証・一貫して解釈し、下流のツールで優先順位付けや自動化に利用できます。含まれていない場合、スコアリングの精度が低下し、advisory間の比較が難しくなります。スコアを含める場合は、公式の計算ツールを使用し、完全なベクトルを含めてください。
  • 関連するCWE分類を含めてください。 CWEは、クロスサイトスクリプティング、SQLインジェクション、信頼できないデータのデシリアライズなど、脆弱性の根本的な弱点を識別します。叙述的な説明とは異なり、CWEは下流のツールやセキュリティチームが扱っている問題の種類を標準化された方法で理解するための手段を提供します。これは、CWEデータが大規模なデータセット全体で脆弱性を分類・フィルタリング・優先順位付け・比較するために使用できるため重要です。組織が関連する問題をグループ化し、ポリシーや報告ルールを適用し、自社ソフトウェアに影響する脆弱性の傾向を理解するのに役立ちます。CWEが具体的であるほど、下流の利用者にとってadvisoryの価値が高まります。

詳細については、明確で完全なセキュリティadvisoryを書くためのベストプラクティスを参照してください。

CVEsのリクエストは意図を持って行ってください。 CVE IDのリクエストは、脆弱性が公開され、公に追跡されることを示します。公開の予定がないままリクエストが行われると、実際にリリースに向かっているadvisoryから時間と注意が逸らされる可能性があります。CVEリクエストを明確な公開意図と整合させることで、努力が最も即時的な影響をもたらす場所に集中し、システムがすべての人にとって応答性を保てるようになります。

メンテナや他の研究者と緊密に連携してください。 高品質なadvisoryデータは共有された文脈に依存します。影響を受けるパッケージ、バージョン範囲、修正内容を整合させることで、ソース間の曖昧さや矛盾する情報を減らすことができます。この規模では、連携の小さなギャップが下流で大きな不整合になる可能性があります。

Advisory Databaseへのプルリクエストを通じてadvisoryの品質向上に貢献してください。 バージョン範囲、パッケージマッピング、修正内容の修正はすべて、開発者が依存する精度を向上させます。

このエコシステムの変化の規模を認識し、参加してください。 脆弱性報告の増加は実質的な進歩を反映しています。問題の発見・修正・開示がこれまで以上に多く行われています。この規模で品質を維持するには、研究者、メンテナ、データ消費者・生産者が同じ目標に向かって協力することが必要です。

全体像

2年前、データベースは月あたり約270件のadvisoryを公開していました。

2026年5月には、システム全体で数千件の追加判断を処理しながら、1,500件を超えるadvisoryを公開しました。

これはより広範な変化を反映しています：

  • より多くのリポジトリが責任ある開示を有効にしている
  • より多くの研究者が脆弱性を報告している
  • より多くのメンテナが修正とadvisoryを公開している
  • 脆弱性エコシステムがより大きな透明性に向かって拡大している

この成長は、私たちのシステムに圧力をかけています。しかし、それは意味のある進歩でもあります。

すべてのadvisoryが可視性を向上させます。すべてのalertがリスクを低減します。

私たちはこの現実に適応するためにスケーリングしており、その進捗を継続して共有していきます。