偽のCVE、AI生成レポート、そして検証の必要性

説得力のある脆弱性レポートを作成するコストが下がりつつあり、その結果、ソフトウェアの保守担当者やセキュリティチームへの影響が大きくなっています。2026年7月、SQLiteに対して6件の共通脆弱性識別子（CVE）が公開され、そのうち2件には深刻度スコア9.8が付けられました。レポートは、メモリ安全性に関するバグを説明し、技術的な解説や概念実証コードも含んでおり、正当なものに見えました。

しかし、JFrogの研究者たちは、レポートが言及していた関数の一部が、影響を受けるバージョンには存在しないことを突き止めました。さらに、概念実証（PoC）のいずれも、主張された脆弱性を再現できませんでした。SQLite自身のCVEページには現在、これら6件の報告はバグではないと記載されており、CVEの記録はその後却下されました。

問題はSQLiteにとどまりません。curlの保守担当者であるDaniel Stenbergは昨年、寄せられるセキュリティレポートの約20％が、AIによって生成された粗悪な内容だと推定しました。GitHubのCVE採番機関（CNA）には、2026年5月に約4,000件のCVE申請が寄せられました。これは、前年同月比で約10倍の増加です。GitHubは、この増加の原因をAIに帰したり、申請の質が低下したと指摘したりしてはいませんが、件数の急増は、脆弱性開示プロセスが過負荷に陥っていることを浮き彫りにしています。

AIによって詳細な脆弱性の主張を作成しやすくなる一方、その主張が正当なものかどうかを判断するには時間がかかります。また、いったんCVEがセキュリティフィードや公開データベースに登録されると、元の記録を訂正しても、すべての複製が自動的に訂正されるわけではありません。そのため、報告された脆弱性と技術的に検証された脆弱性を見分ける必要性が高まっています。

「偽の」CVEとは？

誤って報告された可能性が高いCVEを指して、「偽のCVE」という言葉が日常的に使われています。しかし、偽だからといって、意図的に人を欺こうとしているとは限りません。検証チェックを見落とした静的解析や、入力を攻撃者が制御できるものだと誤解したことが原因の場合もあります。実在する関数について詳しく説明しながら、無効な攻撃経路を主張するレポートもあり得ます。報告された条件が実際には脆弱性ではなかった場合、識別子（CVE ID）が割り当てられた後に取り消されることもあります。これは、意図的にでっち上げられたレポートとは異なります。

見解の相違も、偽のCVEではありません。ベンダーが、悪用可能性、脅威の境界、あるいは信頼できない入力を処理することが関数の意図だったかどうかについて、研究者の調査結果に異議を唱えることはあります。しかし、異議があるからといって、研究者に誤りがあった証拠にはなりません。また、CVEが却下されたからといって、必ずしも捏造だったとは限りません。重複や事務上の理由で却下されることもあります。CVE識別子は独立した技術検証ではありませんが、業界は実際の報告を真剣に受け止める必要があります。

偽のCVEが問題となる理由

現在見られる問題の一つは、調査結果を適切に検証せず、AIを使って脆弱性レポートを作成する人がいることです。こうしたレポートには、詳細な技術解説やコードへの言及、さらにはPoCが含まれることもあり、正当なものに見える場合があります。しかし、SQLiteのCVEで見たように、参照された関数の一部は、影響を受けるバージョンにはそもそも存在しませんでした。

GitHubは2026年、脆弱性の報告が大幅に増加したと発表しましたが、その増加をAIのせいだとはしておらず、申請の質が低下したとも報告していません。懸念されるのは、報告件数が増えれば、調査結果が本物かどうかにかかわらず、調査に必要な作業量も増えることです。

脆弱性レポートのトリアージを経験した人なら、実務上の難しさはすぐにわかるでしょう。AIモデルは、不審なAPI呼び出しを特定し、粗筋程度の悪用シナリオを組み立て、プロらしく見える報告書をすばやく作成できます。そのシナリオが実際に成立するかを判断するには、該当するリリースを正確に確認し、制御フローを追跡し、データがどのように関数へ到達するかを把握し、テスト環境を構築したうえで、主張されているエクスプロイトを実行する必要があるかもしれません。レポートが正確かどうかにかかわらず、同じ手順が必要となり、費用もかかり得ます。

偽のCVEは、評判にも損害を与えかねません。脆弱性の発表は、スキャナーフィードやセキュリティデータベース、検索結果にすぐ広まることがあります。しかし、その後の訂正は、元の情報ほど広く行き渡らない可能性があります。報告に異議が唱えられたり、却下されたりした後も、元の報告を見た顧客に対して、ベンダーが釈明を迫られることがあります。

チームが誤った報告の調査に時間を費やすことで、本物の脆弱性が見過ごされたり、対応が遅れたりするリスクもあります。保守担当者やセキュリティチームのリソースが限られている場合、誤検知を否定するために費やす1時間ごとに、実際のセキュリティ問題の調査に使えた時間が失われます。

自動化で対抗する

新たに押し寄せる大量の報告に対処するため、今も手作業でトリアージを行っている調査担当者は多くいますが、この方法を続けることはできません。自動化は、脆弱性の主張を実際に影響を受けるリリースや構成と照合し、検証するうえで大いに役立ちます。確認すべき質問は次の5つです。

• 構成や権限も含め、攻撃が成立するための前提条件は妥当か？
• 問題とされている関数は、影響を受けるバージョンに存在するか？
• 攻撃者は脆弱なコードに到達できるか？該当する条件下で対象コードが実行される可能性があるか、また攻撃者がそのコードに到達する入力を与えられるかを確認する。
• テスターは、管理されたテスト環境またはPoCを使って、その挙動を再現できるか？
• 観測された挙動は、アドバイザリーに記載されたセキュリティ上の影響を示しているか？

エージェント型ツールは、テスト環境の構築、コードパスの分析、PoCの生成、レビュー用の実行証拠の記録ができます。しかし、あらゆる主張を自動的に検証できるわけではありません。脆弱性が実在する場合でも、環境が不完全だったり、トリガーが適切でなかったりすれば、PoCが失敗することがあります。テスターは、主張された悪用可能性を証明できなくても、クラッシュを再現できる場合があります。こうした注意点があるからこそ、人間の判断が依然として不可欠です。それでも、これらのツールを活用すれば、レポートへの対応にエンジニアリング、脆弱性管理、カスタマーサポートの各チームがさらに多くの時間を費やす前に、再現可能な結論に近づけることができます。

CVEエコシステムの混乱に対処する

簡潔な方針を一つ設けるだけで、偽のCVEの問題がたちまち解決するわけではありません。しかし、報告時により強い証拠を求め、再現状況をより明確に示すことは有効です。異議のあるレコードの扱いを明確にし、下流のデータをより迅速に修正することも役立ちます。研究者には、AIを活用して得た発見を提出前に検証するよう促すべきです。

セキュリティチームとベンダーは、証拠の精査に注力しなければなりません。CVEの深刻度が「重大」と評価されていても、自社の環境で脆弱なコードパスに到達できるかどうかは分かりません。PoCが失敗したからといって、問題がないとは限りません。また、CVE IDを取得したからといって、問題を理解するために必要な技術的調査を怠ってよいわけではありません。

AIは脆弱性を発見する能力を高める一方で、もっともらしく見えても誤った主張を生み出すことも可能にしています。報告が増え続けるなか、組織は検証に投資する必要があります。検証には、テストの構築、結果の再現、前提の確認、証拠を評価しやすくする取り組みが含まれます。エージェント型のセキュリティテストが重要な役割を果たし得るのは、この分野です。