技術概要：AUTOBAXBUILDER

問題定義

大規模言語モデル（LLM）がソフトウェア工学にますます統合される中、LLM によって生成されたコードの正確性とセキュリティを信頼性高く評価することが重要となっています。先行研究は、LLM がセキュリティ脆弱性を含むコードを頻繁に生成し、機能的な正確性を優先してセキュリティを見落としがちであることを示しています。既存の評価フレームワークは、以下の 3 つの主要な限界に苦しんでいます。

1. データ汚染: 手作業で構築されたベンチマークは、将来のモデルのトレーニングデータに必然的に漏洩し、評価の有効性を損ないます。
2. スケーラビリティと拡張性: 新しいベンチマークを作成するには、シナリオの設計、機能的テストの記述、セキュリティエクスプロイトの開発に多大な人的労力を要するため、急速に進化するモデルに追いつくことが困難です。
3. スケーリングの難しさ: より高性能な LLM に挑戦するためには、ベンチマークの難易度を継続的に引き上げる必要があり、これは人間の専門家にとってリソース集約的な作業です。

現在のベンチマークは、多くの場合、正確性とセキュリティを別々のタスクで評価するか、または関数レベルの生成のみに焦点を当てており、アプリケーション全体のバックエンドの複雑さを捉えきれていません。BAXBENCH ベンチマークは、エンドツーエンドの Web アプリケーションバックエンドを評価することでこの課題に対処しましたが、その作成は手作業の人的労力に大きく依存しており、その寿命とスケーラビリティを制限していました。

手法：AUTOBAXBUILDER

著者は、ゼロからコードセキュリティベンチマークタスクの作成をブートストラップする自動化されたエージェント型パイプラインであるAUTOBAXBUILDERを提案します。このシステムは、コード理解能力を備えた LM と、堅牢な実行ベースの信頼性チェックを組み合わせ、人間の介入なしにシナリオ仕様、機能的テスト、およびエンドツーエンドのセキュリティエクスプロイトを生成します。

このパイプラインは、中央の LLM（「オーケストレーター」）によって調整され、「ソリューション LLM」によって生成された参照ソリューションに対して検証される、3 つの反復的改善ステップで動作します。

1. シナリオ提案: オーケストレーターは、明確な攻撃対象領域を露出するように設計された、新規のバックエンドサービス仕様（OpenAPI 形式）を生成します。既存のシナリオタイトルとの照合により新規性を確保します。その後、ソリューション LLM が初期の参照実装を生成します。
2. 機能的テスト生成: オーケストレーターは機能的要件を抽出し、機能的テストを構築します。正確性を確保するため、パイプラインは 2 段階の改善ループを採用します。
   • ソリューションの改善: 失敗した参照ソリューションは、オーケストレーターがテストコードを閲覧して過学習を防ぐことなく、実行ログに基づいて修正されます。
   • テストの改善: オーケストレーターは、テストコード、ソリューションコード、および実行ログの間の関係を分析し、失敗が欠陥のあるテストに起因するのか、それとも欠陥のあるソリューションに起因するのかを判断します。少なくとも 1 つの参照ソリューションがすべてのテストに合格するまで、グローバルな合意が得られるまで反復します。
3. セキュリティエクスプロイト生成: オーケストレーターは、シナリオと参照ソリューションにおける潜在的な脆弱性（CWE）を特定します。各ターゲット脆弱性に対して、エクスプロイトを生成し、対照的なアプローチを用いて検証します。
   • エクスプロイトを参照ソリューション上で実行します。
   • 結果が正しい場合（例えば、脆弱なソリューションが検出された場合）、オーケストレーターはエクスプロイトのロジックではなく、脆弱性の自然言語記述のみに基づき、脆弱性をパッチするか、あるいは導入するかによって「対照的」なソリューションを生成します。
   • エクスプロイトは、ソリューションの安全版と不安全版を正しく区別する場合にのみ受け入れられます。このプロセスは、安全版と不安全版の正確なペアが見つかるまで反復します。

パイプラインには、OpenAPI 仕様の YAML 検証、コードの Python コンパイルチェック、LLM の失敗に対処するための自己批判メカニズムなどのガードレールが含まれています。

主な貢献

1. 自動化されたベンチマーク構築: 最小限の人的介入で、BAXBENCH の設計原則に従って完全に新しいベンチマークを構築するための堅牢な手法。
2. 専門家ベースラインに対する検証: 同一タスクにおいて、専門家によって記述された機能的テストやエクスプロイトを再現するか、あるいはそれらを上回ることを示す検証。これにより、BAXBENCH が報告したセキュリティの上限を実質的に引き締めています。
3. AUTOBAXBENCH: 40 の新規シナリオから構成され、難易度の異なる 3 つの部分集合（Easy、Medium、Hard）に分割された新しいベンチマークの構築と公開。これにより、コードセキュリティベンチマークに利用可能なバックエンドシナリオが 2 倍以上に増加しました。

実験結果

著者は、広範な最先端の LLM（GPT-5、Claude 4.5 Sonnet、Gemini 3 Pro、および各種オープンウェイトモデルを含む）を用いて、パイプラインおよび生成された AUTOBAXBENCH ベンチマークを評価しました。

• パイプラインの検証: 既存の BAXBENCH シナリオに適用された際、AUTOBAXBUILDER によって生成されたテストとエクスプロイトは、人手で作成されたものと高い一致を示しました。具体的には、機能的テストは 80.9% のソリューションで一致しました。パイプラインによって生成されたセキュリティエクスプロイトは、元の人手で作成されたエクスプロイトよりも多くのインスタンスを「不安全」として検出しましたが、これは追加の CWE や攻撃バリエーションの発見によるものです。71 件の生成されたエクスプロイトの人手による監査では、1 つの誤ったエクスプロイトのみが発見されました。
• ベンチマークのパフォーマンス: AUTOBAXBENCH において、評価された最強のモデル（Claude 4.5 Sonnet）でさえ、全体の sec_pass@1（安全かつ正確なソリューションの比率）はわずか 36% でした。「Hard」分割では、この値は 25% まで低下しました。pass@1（機能的正確性）と sec_pass@1 の間のギャップは、機能的に正しい実装の多くが依然としてエクスプロイト可能であることを浮き彫りにしています。
• 効率性: パイプラインは、1 タスクあたりの API コストが 4 ドル未満で、2 時間未満で新しいタスクを生成します。人手による検証を含めても、人手による構築と比較して人的労力を 12 分の 1 に削減します。
• 堅牢性: 構築に使用されたモデルとは異なるモデルの集合を用いたアブレーション研究により、モデルのパフォーマンスにおいて高いランク相関（Spearman $\rho > 0.9$）が示されました。これは、ベンチマークがそれを生成するために使用されたモデルに偏っていないことを示しています。

意義と主張

本論文は、AUTOBAXBUILDER が、LLM のセキュリティ評価におけるベンチマーク汚染とスケーラビリティという重要な課題に対処していると主張しています。汚染されていない高品質なベンチマークの生成を自動化することで、このフレームワークは、LLM の安全なコーディング能力に対する長期的かつ信頼性の高い評価を可能にします。

著者は、誤検知や見逃しを起こしやすい静的解析ではなく、実行ベースのエクスプロイトを使用することで、セキュリティに対する健全な上限を提供していると強調しています。また、このフレームワークは「将来に備えたもの」であり、モデルの能力が向上するにつれて、展開されたバックエンド API の複雑さに近づく、より困難なタスクを生成する能力を備えていると主張しています。本研究は、LLM が機能的なコード生成において進展を遂げた一方で、安全なコードを信頼性高く生成する能力には依然として大きなギャップが存在しており、AUTOBAXBENCH がそのギャップを効果的に露呈させていると結論付けています。