脆弱性報告が過去最高に—GitHubの審査プロセスが限界に直面

脆弱性データの急増—5倍の出力を記録して尚足りない

米GitHubが6月に発表したセキュリティ報告によると、2026年5月の GitHub Advisory Database では 1,560件のレビュー済みアドバイザリ を公開しました（GitHub Blog）。これは通常の月間出力の5倍以上であり、データベース開設以来の新記録です。

しかし、この記録的な出力量でさえ、急増する脆弱性報告に追いつくことができませんでした。

3月から5月にかけて、GitHubは毎月 6,000件以上の審査判定 を行いました。既存アドバイザリの更新、新規アドバイザリの公開、インバウンド審査のすべてで過去のピークを超える活動量です。ただし同じ期間、報告側からの入力は桁違いの加速をみせています。

脆弱性報告の流入が多次元で急増

GitHubのデータから、脆弱性報告の急増が局所的な一時的スパイクではなく、生態系全体の構造的変化であることが見えてきます。

2026年だけで 30,000件以上のCVEが既に公開 され、170万以上のリポジトリ がプライベート脆弱性報告機能を有効化しています。この数字は、オープンソースセキュリティへの関心が爆発的に高まっていることを示唆しています。

個人的には、この流入の加速は必ずしも悪いニュースとは言い切れないと感じます。脆弱性報告の仕組みが使いやすくなり、開発者コミュニティが責任ある報告を実践する傾向が強まった証拠ともいえるからです。ただし、審査体制がこれに追いつけず、修正情報の公開が遅れる可能性が出てきたのは確かに課題です。

審査の遅延—脆弱性の露出ウィンドウが拡大

4月中旬以降、この急増に対応する形で、GitHub内部の公開目標を一貫して達成できない状況が続いています。

初期段階では1週間程度だった審査時間が、5月には数週間に及ぶケースが相当数発生しました。

脆弱性が公開される前の「露出ウィンドウ」が長くなることは、攻撃者に実装前の脆弱性コードを分析される時間を与えることになります。実際、参考記事の事例では、責任あるディスクロージャーを無視して15の製品・プロジェクトの0-day脆弱性コードを一斉に公開した研究者が登場し、既に複数の脆弱性が実際に悪用されています（The Register）。

GitHubは「アドバイザリの品質は変わっていない」と強調しており、レビュー済みアドバイザリは依然として人間による検証を経ています。既存のアラート機能も正常に動作しているとのことです。しかし、新規アドバイザリの処理時間が延びている現実は、開発者にとって自身のプロジェクトへの脆弱性パッチ公開の遅延につながる可能性があります。

GitHub が呼びかける協力の形

こうした状況を受けて、GitHubは脆弱性報告者・研究者・メンテナに対して3つの行動を強く推奨しています。

• 完全な脆弱性データの提出 —概要だけでなく、再現ステップ・影響範囲・修正方法まで含めた情報提供により、審査プロセスを加速できます
• メンテナと研究者の密接な調整 —報告から修正、CVE公開まで、各ステークホルダーの連携を見直すことで、プロセスの重複や齟齬を減らせます
• CVE請求のタイミング —「公開する明確な意図がある場合のみ」という基準を設けることで、不要な審査コストを削減できます

これはセキュリティ研究者やオープンソースメンテナにとって、単なる「お願い」ではなく、全体的な脆弱性対応の品質向上に直結する活動です。個人的には、GitHubがこの段階で「品質と共有責任」という大きな枠組みで問題を投げかけてきたことに注目しています。つまり、脆弱性報告者個人の行動が、生態系全体のセキュリティ速度を左右する時代に入ったということです。

脆弱性生態系の次のステージへ

脆弱性報告の体制変化は、単にGitHubだけの問題ではありません。プライベート報告機能の利用拡大、リポジトリ単位でのアドバイザリ作成機能の普及、CVE要求プロセスの簡素化—これらはすべて、「誰でも脆弱性情報をより簡単に報告・公開できる世界」へのシフトを象徴しています。