GitHub Advisory Database、脆弱性報告数が過去最高に——サプライチェーンセキュリティへの影響

Madison Ficorilli率いるGitHubのアドバイザリデータベースチームは、前例のない脆弱性開示の急増に直面している。CVEとGitHub Security Advisoryを厳選したこのデータベースは、記録的なボリュームを記録。これは、オープンソース依存関係の攻撃対象領域の拡大と、協調的脆弱性開示（CVD）慣行の成熟の両方を反映している。

ボリュームが重要な理由

アドバイザリの増加自体は悪いことではない。より多くの脆弱性が発見され、悪用される前に修正されていることを意味する。しかし、その規模の大きさがキュレーションパイプラインに負荷をかけている。GitHubのチームは、各提出物をトリアージ、検証、エンリッチメントし、正確性とタイムリーさを確保しなければならない。記録的なボリュームになると、バーンアウト、誤検知の見逃し、重要なアドバイザリの遅延のリスクが高まる。

急増の要因

いくつかの要因が重なっている：

• 自動化ツール：SAST、DAST、ファジングパイプラインが、人間が検証するよりも速く結果を吐き出している。
• サプライチェーンの精査：Log4jやSolarWinds以降、すべての依存関係が疑わしい。研究者はトランジティブ依存関係をより深く調査している。
• 報告インフラの改善：GitHub自身のアドバイザリワークフローとCVEプログラムの自動化により、報告者の障壁が低下している。

キュレーションプロセスの内側

GitHubのアドバイザリデータベースは、ただの流し込みではない。厳選されたフィードだ。各エントリは以下を経る：

• 検証：報告は実際の悪用可能な脆弱性を説明しているか？CVE IDは正しいか？
• エンリッチメント：影響を受けるバージョン、CVSSスコア、修復ガイダンスの追加。
• 重複排除：異なるソースからの重複報告の統合。

Ficorilliのチームは、OpenSSF脆弱性開示ワーキンググループの共同議長も務め、CVEプログラムボードにも参加し、スケールする標準を推進している。

運用の現実

記録的なボリュームは、自動的に記録的な品質を意味しない。チームはスピードと正確性のバランスを取らなければならない。急いで発行されたアドバイザリは、深刻度を誤ったり、修正ブランチを見逃したりして、信頼を損なう可能性がある。GitHubのアプローチは、トリアージに自動化を活用しつつ、微妙な判断——特に脆弱性が複数のエコシステム（npm、PyPI、Mavenなど）に影響する場合——には人間をループに残す。

エンジニアがすべきこと

開発者とDevOpsチームにとって、この傾向はいくつかの厳しい教訓を強化する：

• 依存関係を固定し、監査せよ。ロックファイルは出発点に過ぎない。アドバイザリフィードをレビューするプロセスが必要だ。
• Dependabotなどのツールを使用し、パッチ適用済みバージョンへのプルリクエストを自動化せよ。アドバイザリを放置してはならない。
• 貢献せよ。脆弱性を発見したら、GitHubのアドバイザリワークフローを通じて報告せよ。より多くの目がエコシステムを安全にする。

アドバイザリデータベースの記録的なボリュームは、セキュリティエコシステムの成熟の兆しだが、同時にスケールにおける人間参加型キュレーションの脆弱性を露呈している。自動化は役立つが、ボトルネックは依然として専門知識であり、それはすべてのチームが投資すべきリソースだ。