OpenClawの急速な成長がGitHubの脆弱性追跡システムの欠点を明らかにする
OpenClawの急速な成長により、GitHubの脆弱性追跡システムがCVE（Common Vulnerabilities and Exposures）中心の追跡からどれほど離れてきたかが明らかになりました。OpenClawは、わずか3週間で200以上のGitHub Security Advisories（GHSA）を公開し、そのアドバイザリーページにはコマンド実行制御、認証チェック、許可リスト論理、プラグイン境界などに関する約255の開示が掲載されています。
これらの問題の一部しかCVE識別子を持っておらず、開発者がGitHubで見ることができる情報と企業ツールがCVEフィードを通じて検出する情報の間のギャップが生じています。
GitHubとCVEの間のギャップ
脆弱性情報企業のVulnCheckは、CVEプロジェクトの研究者作業グループに「DIBS」を要求し、170のOpenClawアドバイザリーがCVEを持たないことを指摘しました。DIBSは、CVEナンバリングオーソリティ（CNA）間で特定の脆弱性を評価し、CVE識別子を割り当てる意図があることを示す非公式な信号です。
VulnCheckは、顧客の関心と武器化のリスクを理由に、CVEを持つことでこれらの問題を追跡し、優先順位をつけることが容易になると主張しました。しかし、MITREのTL-Rootは、DIBSは個々の脆弱性を特定し、CVE基準を満たす場合にのみ使用されるべきであり、特定のサプライヤーを「ホット」カテゴリとして大量予約するべきではないと反論しました。
GHSAとCVEの間の構造的な緊張
GHSAの公開は低摩擦で、研究者が報告し、メンテナーが公開し、外部の調整は必要ありません。一方、CVEの要求はCNAと調整し、メタデータをフォーマットし、プロセスが完了するまで待つ必要があります。そのため、多くのプロジェクトはGHSAのみの開示をデフォルトとしており、後からもしくは全くCVEを追加しない場合があります。
しかし、多くの企業スキャナーやSBOMツール、パッチパイプライン、コンプライアンスフレームワークは、CVE識別子を中心に回っています。そのため、GHSAのみで開示された脆弱性は、これらのシステムに対して実質的に見えなくなる可能性があります。
GitHubのアドバイザリーバックログ
2024年のUCイリノイ大学の調査では、2024年4月時点でGitHubのアドバイザリーデータベースには213,594件以上の未レビューのアドバイザリーがあり、現在のペースで95年以上かかると推定されています。
最近の学術研究では、2026年のブラジルフリウメン連邦大学の研究では、288,604件のGHSAのうち約8.2%しかGitHubレビューされておらず、265,000件以上のレコードが未レビューであることが示されています。
独立した追跡とコミュニティの役割
OpenClawの開示バーストは、これらのシステムを橋渡しするための独立した追跡をすでにインスピレーションとしています。セキュリティエンジニアのジェリー・ギャンブリンは、OpenClaw CVEとセキュリティアドバイザリートラッカーを構築し、レポアドバイザリー、GitHubアドバイザリーデータベース、CVEプロジェクトのcvelistV5を統合しました。
また、DIBSの議論は、エコシステムがCVEを単一の真実の源としてどれだけ依存すべきかという深い議論を引き起こしました。一部の実践者は、現代の脆弱性管理が複数の識別子とソースに依存していると主張し、詳細なGHSAが存在する公開データベースがある場合、CVEの必要性を疑問視しています。
結論
AIエージェントプラットフォームのようなOpenClawは、この分断が再発する可能性が高いです。高速なアドバイザリーストリームは、GitHubとCVEプロセスを圧迫し、ベンダー、研究者、企業がCVEの調整に固執するか、ツールを調整してGHSAと他のアドバイザリーシステムを最初から信号として扱うかを決定する必要があるでしょう。