アドバイザリデータベースの内部と脆弱性情報量が記録を更新した際の対応

2026 年 5 月、GitHub Advisory Database は 1,560 のレビュー済みアドバイザリを公開しました。これは通常の月間出力の 5 倍以上であり、同データベース史上最高記録です。 それでもなお、追いつくには足りませんでした。 過去数ヶ月にわたり、脆弱性エコシステムは根本的な変化を遂げました。プライベートな脆弱性情報報告、リポジトリアドバイザリ、CVE リクエストにおける入力が増加し、全体として新たな運用規模へと押し上げられています。 本ブログ記事は、脆弱性報告の進化を追跡する GitHub コミュニティ内の継続的な議論、および PVR（Private Vulnerability Report）と Advisory Database のロードマップに関する開発動向を踏まえたものです。そのスレッドで繰り返し指摘されているテーマは、プラットフォームの変更がアドバイザリの選別やデータ品質に与える下流への影響です。これは、脆弱性報告における「品質」と「共有責任」の重視へと移行する GitHub のより広範な動きと一致しており、これが結果としてアドバイザリデータの選別および維持管理の方法を直接的に形作っています。 TL;DR（要約） 新規アドバイザリのレビューにかかる時間は、脆弱性の量と複雑性が大幅に増加したため長くなっています。ただし、アドバイザリの品質に変化はありません：レビュー済みアドバイザリは依然として人間による検証を経ており、既存のアラートも通常通り機能しています。ご支援いただける場合は、以下の 3 点に焦点を当ててください。完全な脆弱性情報の提出、メンテナーおよび研究者との緊密な連携、そして公開する明確な意図がある場合のみ CVE の発行を依頼することです。 記録的な出力と前例のない入力 5 月は単発の急増ではありませんでした。3 月から 5 月にかけて、私たちは毎月 6,000 件以上のアドバイザリ決定を維持しました。これには既存のアドバイザリの更新、新しいアドバイザリの公開、および流入するアドバイザリのレビューが含まれ、過去のどの 3 ヶ月のピークも上回りました。 同時に、すべてのソースからの流入が加速しました: プラットフォーム全体でのプライベート脆弱性レポートは、1 月の週あたり約 550 件から、5 月の大半で週あたり 3,000 件以上に増加しました。 リポジトリアドバイザリは、週あたり約 650 件から 5,000 件以上へと拡大しました。 GitHub CNA CVE リクエストは、5 月だけでほぼ 4,000 件に達し、前年比で約 10 倍となりました。 CVE プログラムはすでに 2026 年に 30,000 件以上の CVE を公開しています。 プライベート脆弱性レポート機能を有効にしたリポジトリの総数は 170 万件を超えています。 ![image](https://github.blog/wp-content/uploads/2026/06/613839791-af0d8e48-215f-48c7-8f0c-16ef531592f7.png?resize=1024%2C640) これは局所的な急増ではありません。これは脆弱性開示エコシステム全体における構造的変化を反映しています。 影響 4 月中旬以降、この急増により、私たちは公開に関する内部目標を一貫して達成できていませんでした。処理時間はまず約 1 週間となり、その後、意味のある割合で数週間に延びました。公開までの時間が長くなると、曝露期間（エクスポージャーウィンドウ）が増加する可能性があります。私たちはこれを深刻に受け止めており、迅速性は本データベースが提供する価値の核心的な一部です。 まだ機能していること 当社のデータパイプラインと公開インフラは、この期間を通じて稼働を続けています。インポートは実行され、データの整合性は保たれており、公開されたアドバイザリも正確です。本日レビュー済みステータスに達したアドバイザリは、以前と同じ品質基準を満たしています。 CVE 割当の質は依然として高い水準を維持しています。割当率は今回の急増期間中を通じて 91〜94% の範囲で推移しており、これは過去の規範と同等かそれ以上に良好であり、受け取るリクエストに明確な劣化が生じていないことを示しています。 問題はスループットにあります。アドバイザリデータを検証し、拡張し、公開するシステムは機能していますが、現在はその設計上の処理能力を超えた量と複雑さに直面して稼働しています。 作業の均一性はない すべてのセキュリティアドバイザリが同じレベルの労力を必要とするわけではありません。一部のアドバイザリは良好なフォーマットで到着します。詳細には影響を受けるパッケージとその関連エコシステムが明確に記載され、バージョン範囲も文書化されており、修正箇所もタグ付けされています。キュレーターであれば、これらを数分以内に検証して公開できます。 しかし、増加する割合の incoming advisories（着信アドバイザリ）では、より多くの調査が必要です： パッケージの曖昧さ解消。アドバイザリの詳細には「foo」と記載されているものの、それが npm 上の foo なのか、PyPI 上の python-foo なのか、それとも Maven 上の無関係な foo なのかを特定する必要があります。上位ソースデータでエコシステムが指定されていない場合、キュレーターがこれを判別します。 バージョン範囲の再構築。多くのセキュリティアドバイザリには影響を受けるバージョン範囲が含まれていないか、実際のリリース履歴と一致しない範囲が記載されています。キュレーターはコミット、変更ログ、タグを追跡して、実際に影響を受けている部分を特定します。 マルチエコシステム向けアドバイザリ。一部のプロジェクトでは、同じ機能を持つライブラリの.NET実装（NuGet）とJavaScript実装（npm）など、複数のレジストリにパッケージを配布しています。共有ロジカルに脆弱性がある場合、両方に影響が及びます。これには複数のデータソースにわたる独立した検証が必要です。 競合する上位元データの存在。CVEレコード、メンテナによるアドバイザリ、コミット履歴の間で、何が影響を受けるかについて不一致が生じる場合があります。その場合、誰かが真実を確定する必要があります。 歴史的にはより単純なアドバイザリが主流であり、困難なものは吸収可能でした。しかし、件数が急増すると、キューに両方が混在し、複雑なものほど不均衡に長い時間を要するようになり、複合的な影響が生じます。現在ではその混合比率が非常に重要になっています。これは単なる作業量の増加ではなく、著しく複雑化していることを意味します。 「レビュー済み」の真の意味 レビュー済みのアドバイザリとは、単なる再公開された記録ではありません。それは検証の結果です。 キュレーターは以下の作業を行います： - 脆弱性を正しいエコシステムのパッケージにマッピングする - 影響を受けるバージョンと修正されたバージョンをリリース履歴に対して検証する - 上位元の情報の正確性を確認する - 重複や整合性の有無をチェックする - 分類とスコアリングを検証する これにより、下流のツールが追加検証なしでこのデータを信頼できるようになります。 検証をスキップして公開速度を上げると、大規模な誤検知が増加し、遅延よりもむしろリスクが高まる可能性があります。 生態系全体の変革 この傾向は GitHub だけに留まりません。 報告され、公開された脆弱性の数は急速に増加し続けており、生態系全体の組織がこの変化に適応しています。 システムは設計通りに機能しています。これまでにない数の脆弱性が報告され、開示され、追跡されています。これが、アドバイザリキュレーションの過程を含む下流のプロセスに圧力をかけています。 現在私たちが行っていること コミュニティからの貢献の質とスループットの向上です。コミュニティからの貢献は、Advisory Database（アドバイザリデータベース）を改善する上で重要な要素であり、すべての貢献は他のどのアドバイスと同様の検証基準に対してレビューされます。私たちはトリアージと優先順位付けを強化し、高品質な提出物が早期に特定され、一貫してレビューされ、キューをより迅速に通過できるようにしました。これにより、現在のボリュームに対応しつつ、高品質で信頼性の高いデータセットを維持するという主要な目標を強化しています。 キュレーションを支えるシステムの拡張です。バックエンドのキュレーションシステムの容量の一部を増強し、持続的なスループットの高さに対応可能にし、分析やキュー管理をサポートするデータインフラストラクチャの近代化も継続して行っています。 AI を活用した研究ツールの構築。私たちは、アドバイザリレビューの研究フェーズにおいてキュレーターに AI による支援を提供するツールを開発・導入しました。すべての決定は依然としてキュレーターが行いますが、定型の研究作業をより迅速に完了させることで、高品質なアドバイザリの作成が可能になります。 最も効果的な分野での自動化の拡大。私たちは、上位 CVE 情報からより多くのデータを抽出するための自動化や、コミュニティからの貢献が既にレビュー済みのアドバイザリとどのように相互作用するかを処理する仕組みを改善しました。この取り組みにより、意思決定にかかる時間を短縮しつつ、品質基準を低下させることなく実現しています。 ドキュメントとトレーニングへの投資。私たちは運用ドキュメントを大幅に拡充しました。これにより、新しいチームメンバーのオンボーディングを迅速化し、チーム全体での一貫性を向上させています。 今後構築するもの この新たなスケールに対応するため、私たちは以下の分野に投資を行っています: 最も一般的なケースにおける 1 アドバイザリあたりの所要時間の削減。流入するアドバイザリの多くは、適切なパッケージの特定、バージョン範囲の確認、修正の有無の確認など、予測可能なパターンに従った研究を必要とします。私たちはこれらのパターンを加速させるツールに投資しており、キュレーターが人間の判断を要する真に曖昧なケースに時間を割けるようにしています。 リスクベースのレビュー優先順位付けの高度化。パッケージの使用状況、積極的な悪用の実証、エコシステムへの影響など、追加のリスクシグナルを活用して優先順位付けを行うことを検討しており、最も重要なアドバイザリがまずユーザーに届くようにします。 アップストリームデータソースとのフィードバックループの改善。キュレーション時間の大きな割合は、不完全または不正確なアップストリームデータの修正に費やされています。私たちは、特にリポジトリ GitHub Security Advisory および Private Vulnerability Reporting データの検証を強化することで、取り込むソースとの統合をより緊密にするよう投資を行っており、データ品質の問題がレビューキューではなく発生源に近い段階で解決されるようにしています。 透明性を継続して維持します。進捗があるたびに更新情報を共有していきます。状況が改善すればその旨をお伝えし、新たな課題に直面した際も同様にお知らせいたします。 これがあなたにとって何を意味するか Dependabot ユーザー：既存の警告は影響を受けません。新しいアドバイザリがトリガーされるまで時間がかかる場合がありますが、重大な問題は優先されます。 API およびフィード利用者：レビュー済みのデータは正確に維持され、未レビューのアドバイザリは表示されますが、まだ検証されていません。 メンテナー：リポジトリアドバイザリは引き続きグローバルデータベースへ流れます。優先順位付けは、プロジェクトへの影響や深刻度など複数の要因に基づいて行われます。 あなたが協力できること 脆弱性情報レポートには完全なデータを含めてください。影響を受けるバージョン範囲、根本原因、明確な再現手順を提供することは、アドバイザリがどの程度迅速かつ正確にレビューされるかに直接的な違いをもたらします。このデータが完全であれば、キュレーションは数分で完了します。しかし不完全な場合、キュレーターはソースコード、リリース履歴、矛盾するアップストリームのシグナルから欠落した詳細を再構築しなければなりません。この規模では、これらのギャップはすぐに蓄積されます。高品質なアップストリームデータは、エコシステム全体の速度と精度の両方を改善するための最も効果的な方法の一つです。 適切なアドバイザリ詳細を含めてください。ベストプラクティスガイドにはエコシステムの分類、パッケージ名、バージョン範囲のフォーマットが記載されていますが、さらにいくつかの詳細を追加することで、GitHub Advisory Database へのレビューおよび公開の迅速さと正確性に直接的な違いが生じます。 レジストリに表示される通りのパッケージ名を使用してください。アドバイザリのパッケージ名は、リポジトリやプロジェクト名ではなく、必ずレジストリと一致させる必要があります。ダウンストリームシステムは、アドバイザリを影響を受ける依存関係にマッチングさせるためにレジストリ識別子に依存しています。名前が誤っているか欠落している場合、アラートを確実に生成できず、影響を受けるユーザーが通知されない可能性があります。レジストリ名を使用することで、アドバイザリを正しくリンクし、インデックス付けし、配布することが可能になります。 影響を受けるすべてのパッケージをリストアップしてください。一部の脆弱性は、プロジェクト内の複数のパッケージに影響を与える可能性があります。各影響を受けるパッケージは、それぞれのエコシステム、パッケージ名、バージョン範囲とともに個別にリストする必要があります。アドバイザリはパッケージレベルで処理されるため、1 つでもパッケージを見落とすと、その依存関係にあるユーザーへの通知も漏れてしまいます。既知の影響を受けるすべてのパッケージを含めることで、カバー率が向上し、影響を受けたすべてのユーザーにアラートが届くことが保証されます。 完全な CVSS ベクトル文字列を提供してください。GitHub Advisory Database は CVSS 3.1 および 4.0 をサポートしています。「High」などの深刻度ラベルは簡潔な要約ですが、完全な CVSS ベクトル文字列には、攻撃の複雑さ、必要な権限、ユーザーの相互作用など、脆弱性をより詳細に記述する属性が豊富に含まれています。この構造化された情報により、深刻度の検証が可能になり、一貫した解釈が行われ、下流のツールによる優先順位付けや自動化に活用できます。これがない場合、スコアリングは精度が低下し、アドバイザリ間での比較が困難になります。スコアを含める場合は、公式の計算機を使用し、完全なベクトルを含めてください。 関連する CWE（Common Weakness Enumeration）分類を含めてください。CWE は、クロスサイトスクリプティング、SQL インジェクション、信頼できないデータのデシリアライズなど、脆弱性の背後にある根本的な欠陥を特定します。物語形式の説明とは異なり、CWE は下流のツールやセキュリティチームに対して、取り扱っている問題の種類を理解するための標準化された方法を提供します。これは重要です。なぜなら、CWE データは、大規模なデータセット全体で脆弱性を分類、フィルタリング、優先順位付け、比較するために使用できるからです。これにより、組織は関連する問題をグループ化し、ポリシーや報告ルールを適用し、自社のソフトウェアに影響を与える脆弱性のパターンを理解することができます。CWE が具体的であればあるほど、下流の消費者にとってそのアドバイザリはより有用になります。 詳細なガイダンスについては、明確で完全なセキュリティアドバイザリの作成に関するベストプラクティスをご覧ください。 CVE（Common Vulnerabilities and Exposures）の要求には意図を持って臨んでください。CVE ID の要求は、脆弱性が公開され追跡されることを示すものです。公開する計画がないまま CVE を要求すると、実際にリリースに向けて進行中のアドバイザリから時間と注意がそらされてしまう可能性があります。明確な公開意図と整合性のある CVE 要求を行うことで、努力が最も即座に影響力を持つ場所に集中し、システムをすべての関係者に対して応答性の高い状態に保つことができます。 メンテナーや他の研究者と密接に連携してください。高品質なアドバイザリデータは、共有された文脈に依存します。影響を受けるパッケージ、バージョン範囲、および修正策を整合させることは、ソース間での曖昧さや矛盾する情報を減らすのに役立ちます。この規模では、連携における小さな隙間が、下流で大きな不整合として現れる可能性があります。 アドバイザリデータベースに対してプルリクエストを投稿することで、アドバイザリの品質向上に貢献してください。バージョン範囲、パッケージマッピング、または修正策に対するあらゆる修正は、開発者が依存する精度を高めるものです。 このエコシステムの変化の規模を認識し、その一員として参加してください。脆弱性報告数の増加は、実際の進歩を反映しています。これまで以上に多くの問題が発見され、修正され、公開されています。この規模で品質を維持するには、研究者、メンテナー、データ消費者およびプロデューサーが同じ目標に向かって協力することが不可欠です。 大きな視点 2 年前、データベースでは月間約 270 のアドバイザリが公開されていました。 2026 年 5 月には、システム全体で数千の追加決定を処理しながら、1,500 を超えるアドバイザリが公開されました。 これはより広範な変化を反映しています: - 責任ある開示を可能にするリポジトリが増えています。 - 脆弱性を報告する研究者が増えています。 - 修正策とアドバイザリを公開するメンテナーが増えています。 脆弱性エコシステムは、より高い透明性へとスケールしようとしています。 この成長は、私たちのようなシステムに圧力をかけます。しかし同時に、意味のある進歩を表しています。 すべてのアドバイザリが可視性を高め、すべてのアラートがリスクを低減します。 私たちはその現実に対応するために規模を拡大しており、進捗状況についても引き続き共有していきます。 「アドバイザリデータベースの内部と脆弱性数が記録を更新した際に何が起こるか」という投稿は、最初に The GitHub Blog で公開されました。

アドバイザリデータベースの内部と脆弱性情報量が記録を更新した際の対応

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト