LLMの脆弱性検証成果物を再実行した結果、30件中、修正版による反証を通過したのは10件のみ

新たな研究では、LLM／AIエージェントが生成した脆弱性検証成果物を、一般公開されている、実行できる、候補シグナルを生成する、指定された脆弱性の再現を意味論的に確認できる、という4段階に分類した。研究者らはまず、2023年から2026年までに発表された104本の論文からコンセンサスコーパスを構築したが、主要な成果物へ一般公開でアクセスできたのは59本だけだった。さらに18本を抽出し、ワークフロー全体を再実行した。クリーンな環境で成功したのは10本のみで、既存の依存パッケージをインストールするなどの環境修正を加えても11本に増えただけだった。

さらに注目すべきなのは、102件のCVEケースを含むベンチマークに対して実施されたケース別監査である。58件では、実行スクリプト内のCVE番号が、ディレクトリで対象として宣言されているCVEと一致していなかった。シグナルが発生したケースについて、研究者らはクラッシュ、ステータスコード、成功フラグを確認するだけでなく、シグナルがCVEの実際の事後条件と一致するか、正常な入力では発生しないか、同じPoCが修正版では機能しなくなるか、という3項目も検査した。

その結果、修正版でのテストが可能で判定まで行えた30件のうち、シグナルが消失したのは10件だけで、残る20件では同じように発生し続けた。また、対応する負の対照を追加した19件のうち、7件で偽陽性が発生した。条件を最も厳格なE1エビデンスとして統合すると、シグナルが発生したケースのうち完全に確認できたのはわずか2件だった。論文では、問題の例としてCVE-2020-1967を挙げている。このテストは`SSL_check_chain`へ直接NULL値を渡していたため、NVDで修正版とされているOpenSSL 1.1.1gでもクラッシュした。つまり、TLS 1.3の拡張フィールドが実際に関係する脆弱性経路は再現されていなかった。

サイバーセキュリティAIエージェントの評価を構築する際の工学的な要点は、「脆弱なバージョンでは発生し、修正版では発生せず、正常な入力でも発生しない」という条件をペアテストとして実装し、イメージ、依存関係、判定条件を固定することにある。ただし、現時点の数値は依然として探索的な結果である。ケース単位の分析は主に単一のベンチマークに集中しており、負の対照と修正版による反証テストは、シグナルが発生した全ケースをまだ網羅していない。また、Dockerのリソース制約やネットワーク制限が実行可能率に影響した可能性もある。今後、より多くの独立したベンチマークで同程度の偽陽性率を再現できるかどうかが、この問題の一般性を判断する鍵となる。