今度はAIが偽の脆弱性を作り出し、エコシステムを汚染する事態になっています。先週NVDに掲載され、CISAによるエンリッチメント情報まで付与された「Critical」「High」評価のSQLite関連CVE群が、実は技術的にはでたらめだったことがセキュリティ研究者の調査で判明しました。広く使われているデータベースにまでこうした情報が入り込んでしまう経路は、CVEパイプラインの脆弱性を浮き彫りにしています。
ソフトウェアサプライチェーンセキュリティ企業のJFrogは先週、無名の新しいGitHubリポジトリが公開したより大規模なバッチに含まれていた6件のSQLite脆弱性報告について、いずれも完全なでたらめだったと報告しました。これらのアドバイザリをAI検出ツールにかけたところ、AIによって生成された可能性が高いことが示唆されたとJFrogは述べています。さらに実際にテストしたところ、CVSSスコアが9.8から7.5までのこれら6件のSQLite報告は、いずれも再現可能な脆弱性を記述したものではなかったことが分かりました。
そのうちの1件は、このオープンソースデータベースにおける「解放後使用（use-after-free)」の脆弱性だとされ、Red Hatが当初は最大値である10.0のCVSSスコアを付与した(後に引き下げ)ものでしたが、この脆弱性が依拠するとされる関数は、対象のSQLiteバージョンには存在していませんでした。もう1件、CVSSスコア9.1とされた別のUAF脆弱性は、参照元のソースコード行が、そもそも該当の欠陥とは無関係な箇所を指していました。JFrogが付属の概念実証(PoC)コードをテストしたところ、メモリリークやエラーもなく、正常なクエリとして実行されただけでした。同じリポジトリから見つかったその他4件のSQLite関連CVEについても、JFrogがテストした結果、同様に架空のものであることが判明しています。
問題のGitHubリポジトリに含まれていた残り49件のCVEは、オープンソースのRAW画像処理ライブラリlibrawと、Arduino向け音声デコードライブラリESP32-audioI2Sにおけるセキュリティ脆弱性だと主張するものでした。JFrogはこれらについてはそこまで徹底的な検証は行っていないものの、1件を除いて残りはすべて同様に架空のものだとしています。唯一の例外についても、「検証されていないCVEメタデータに包まれてはいるものの、実際のバグが含まれていた」と説明しています。
金曜日にOpenwallのOSS-Securityメーリングリストに投稿されたメッセージによれば、MITREはこのリポジトリに含まれる根拠のない脆弱性報告をすべて却下したとのことです。しかし、この一件は重要な教訓とすべきだと、投稿者でありOracle Solarisのエンジニアでもあるアラン・クーパースミス氏は指摘しています。
「MITREをはじめ、自分たちが開発していないコードに対してCVEを割り当てるCNA(CVE採番機関)の大半は、性善説に基づいて運用されており、CVE申請者が提供する情報は事前に検証済みであると信頼する前提で動いています」とクーパースミス氏はOSS-Securityへの投稿で述べています。「CNA自身がその報告内容を検証できる立場にないことも少なくありません」
JFrogが指摘するように、米国立標準技術研究所(NIST)は米国の国家脆弱性データベース(NVD)を管理しており、以前はCVEレコードがデータベースに登録された後、手作業でレビューとエンリッチメントを行うことで信頼できる最後の砦としての役割を果たしていました。しかし、脆弱性報告の急増と運用面での課題が重なった結果、2024年にこのプロセスは大幅に停滞し、同機関では処理しきれないレコードの滞留が拡大していきました。
2024年末までに、未処理のCVEは17,000件超にまで積み上がりました。NISTは請負業者の支援を受けて2024会計年度末までにこの滞留を解消するという計画を掲げていましたが、実現しませんでした。滞留はその後も膨らみ続け、2026年5月に公表された商務省監察官室(Inspector General)の報告書によれば、2025年末までに27,000件を超えるまでになったとのことです。
さらに事態を悪化させているのが、商務省監察官室が下した結論です。同室は、滞留解消のために割り当てられた予算について、NISTが「戦略的計画の欠如と決断力を欠いた対応」によってこれを浪費し、その結果として未処理案件の山がなお増加し続けている、と結論付けています。
言い換えれば、現在のパイプラインには、申告された脆弱性のすべてについて独立した再現検証を義務付けるチェックポイントが存在しないということです。
「今日のシステムでは、いかなる段階においても概念実証やバグの再現が実際には要求されていません。そのため、もっともらしく見える偽のアドバイザリがパイプラインをすり抜けて、GitHub Security Advisories、下流のデータベース、さらには企業のスキャナーにまで入り込んでしまう可能性があります」とJFrogは述べています。「この一件は、自動化された脆弱性取り込みプロセスに内在する構造的な問題を示すものです」
これがセキュリティ担当者にとって何を意味するかと言えば、汚染された脆弱性データベースへの対応を強いられるだけでなく、質の悪いアドバイザリのせいで、本来なら実在の問題の追跡に充てるべき時間が無駄になりかねないということです。信頼されているデータベースであっても、未検証のレコードを取り込んでしまう可能性があるため、JFrogは新たに公開されたCVEに対して防御担当者が対応に動く前に、いくつかの確認事項をチェックするよう推奨しています。
まず、ベンダー側がその問題を裏付けていない場合(実際、SQLiteのメンテナーはこれら偽のCVEを一切認めていません)は、その脆弱性はまず正当なものではないと考えられます。リポジトリの参照フィールドにコミットハッシュやプルリクエストが存在しないことも、AIによる出鱈目であることを示す兆候です。同様に、CPE製品定義の欠落といった不審なメタデータもその一例です。最後に、コード参照が実在の関数と一致していない、あるいは指し示している箇所が問題とされる欠陥とは無関係な部分である場合、それは単なるAIのハルシネーションである可能性が高いといえます。
JFrogはこの調査結果を、GitHub Security Advisoryチーム、Red Hat、そしてNVDに報告しました。同社によれば、これらの組織はいずれも該当のCVEにフラグを立てるか、削除する対応を取ったとのことです。一方、GitHubについてはまだ対応が取られていないとJFrogは述べています。本誌はGitHubに対し、なぜ問題のリポジトリが依然として公開されたままなのか問い合わせましたが、回答は得られませんでした。
なぜこのようなことをする人物がいるのか、その動機についてJFrogは、自身の研究実績を偽の報告によって水増しする狙いがあったのではないか、あるいは自動CVE識別ツールが何を実際の脆弱性として検出するかに影響を与えようとした可能性があると推測しています。ただし、JFrogが本誌に語ったところによれば、いずれもあくまで推測の域を出ないとのことです。いずれにせよ、こうした根拠のない54件のCVEは、今後さらに頻発すると見られる問題のほんの一例に過ぎないと、JFrogのセキュリティ研究者であるアフェック・バーガー氏は述べています。
「生成AIの登場により、もっともらしく見えるアドバイザリを作成するのに必要な労力はほぼゼロにまで下がりました。一方で、それを検証する側、つまりソースコードをレビューし、該当バージョンをビルドし、PoCを再現するために必要な労力は何も変わっていません」とバーガー氏はメールで本誌に語っています。「この非対称性のせいで、たとえ十分なリソースを持つ防御担当者やメンテナーであっても、届くすべての報告を手作業で検証することはもはや不可能です……これはAI時代において業界全体が直面している課題だといえます」 ®
