Why LLMs Fail: A Failure Analysis and Partial Success Measurement for Automated Security Patch Generation

この論文は、Vul4J ベンチマークを用いた大規模言語モデル（LLM）によるセキュリティパッチ生成の分析を通じて、構文は正しいがセキュリティ修復の意図を誤解するケースが多く、機能維持とセキュリティ修復の間に大きな乖離があることを明らかにし、厳格な検証の必要性を説いています。

要約

この論文は、**「AI（大規模言語モデル）がセキュリティの穴を塞ぐ（パッチを作る）仕事ができるのか？」**という問いに、徹底的に分析して答えたものです。

結論から言うと、**「AI はコードの『文法』は完璧に覚えているが、セキュリティという『意味』を理解するのが苦手」**という結果になりました。

まるで、**「完璧な料理のレシピ本は読めるが、毒入りキノコを見分けることができない料理人」**のようなものです。

以下に、この研究の核心を日常の言葉と比喩で解説します。

---

1. 実験の舞台：AI に「穴埋め」をさせた

研究者たちは、64 種類の「Java というプログラミング言語のセキュリティの穴（バグ）」を用意しました。そして、AI（Gemini というモデル）に「この穴を塞いで、元の機能は壊さないで」と頼みました。
AI は 319 枚の「修理案（パッチ）」を作りましたが、その結果はあまりにも衝撃的でした。

2. 結果：AI の「修理」はどんな感じ？

🍎 全体の合格率は 25% だけ

AI が作った修理案のうち、「完全に安全で、かつ元の機能も壊していない」ものは、たったの24.8%（約 4 人に 1 人）だけでした。

💣 最大の失敗：「安全じゃないのに、壊れていないふり」

最も多い失敗（51.4%）は、**「セキュリティも機能も両方ダメ」**という状態でした。

• 比喩： 家の鍵穴を塞ぐために、壁を壊してドアごと取り外してしまったような状態です。
• 理由： AI は「コードの書き方（文法）」は間違えていませんが、「どう直せばいいか（戦略）」を根本的に勘違いしていました。

🎭 最も危険な失敗：「一見完璧な罠」

10.3% のケースで、**「機能は完璧に動くのに、セキュリティ穴は塞がっていない」**というパッチが生まれました。

• 比喩： 泥棒が侵入できないように見せかけた「偽の鍵穴」です。
• 危険性： これらは通常のテスト（機能テスト）を全てパスしてしまうため、「安全だ！」と誤って本番環境に導入されてしまう可能性が最も高いです。特に「アクセス権限」に関するバグでこの傾向が強かったです。

3. AI の「二面性」：機能は守れるが、安全は守れない

この研究で面白いのは、AI の**「機能を守る力」と「安全を守る力」のバランスが極端に偏っている**ことです。

• 機能スコア（83%）： 元のアプリが動いているか？ → バッチリ！
• セキュリティスコア（25%）： 穴は塞がったか？ → 全然ダメ。

**「安全にするために機能を犠牲にする」というジレンマは存在しませんでした。AI は「機能は守れるのに、なぜか安全が守れない」という、「できることとできないことの壁」**にぶつかっているのです。

4. なぜ失敗するのか？「意味」がわからないから

AI が失敗する主な理由は、**「文法エラー」ではなく「意味の誤解」**でした。

• 例：入力値のチェック（CWE-20）
  • AI は 95% の確率でコードを正しく書けます（文法 OK）。
  • しかし、**「0%」**の確率でバグを直しました。
  • 理由： 「どんな入力が危険か」という文脈や常識を理解していないからです。
• 例：無限ループ（CWE-835）
  • こちらは 45% の確率で直せました。
  • 理由： 「ループを止める」というのは、**「機械的なルール」**で解決できるからです。

つまり、「単純なルールで直せるもの」は得意ですが、「状況に応じて判断が必要なもの」は苦手なのです。

5. 重要な発見：「半分成功」は存在しない

多くの人は「AI が 80% 成功したら、少し直せば 100% になるだろう」と考えがちです。しかし、この研究では**「半分成功（Near-success）」という中間状態がほとんど見られませんでした**（0.3% だけ）。

• 比喩： 暗号を解くとき、AI は「全開で解ける」か「全く解けない」かの**「二極化」**しています。
• 意味： 「少しヒントを与えれば直る」という段階ではなく、「根本的な思考の癖」を変える必要があるということです。

6. 私たちへの教訓

この研究から得られるメッセージは以下の通りです。

1. AI の作ったセキュリティ修正は、そのまま使ってはいけない。
   • 機能テストに合格しても、実は危険な穴が開いている可能性があります。必ず人間が「セキュリティの専門家」として再チェックする必要があります。
2. バグの種類によって AI の能力は違う。
   • 「入力チェック」のような複雑な判断が必要なバグには AI は不向きです。一方、「無限ループ」のような単純なバグには使えます。
3. 「機能」と「安全」は別物。
   • 「安全にするために機能を犠牲にする」という考え方は間違いです。AI は機能を壊さずに安全にできる可能性はありますが、今のところ「安全」を達成する知能が足りていません。

まとめ

この論文は、**「AI は優秀な『コピペ屋』や『文法チェック係』にはなれるが、まだ『セキュリティの守り神』にはなれない」**と教えています。

AI がセキュリティの穴を塞ぐためには、単にコードを書くだけでなく、「なぜそれが危険なのか」という深い理解を教える必要があります。それができるようになるまでは、人間が最終的なチェック役を務め続ける必要があります。

技術概要

論文要約：LLM による自動セキュリティパッチ生成の失敗分析と部分的な成功の測定

論文タイトル: Why LLMs Fail: A Failure Analysis and Partial Success Measurement for Automated Security Patch Generation
著者: Amir Al-Maamari (University of Passau)

1. 研究の背景と問題定義

大規模言語モデル（LLM）は、機能バグの修正（Automated Program Repair: APR）において Defects4J や SWE-bench などのベンチマークで成果を上げています。しかし、セキュリティ脆弱性の修正においては、その有効性が十分に解明されていません。

従来の APR は機能テストスイートに合格するパッチを「妥当（plausible）」と判断しますが、セキュリティ分野では以下の課題が存在します。

• テストスイートは期待される動作を検証するだけで、悪意のある入力（攻撃）に対する防御を検証しない。
• 機能は正常に動作しても、システムが依然として脆弱なまま（「サイレントな失敗」）のパッチが存在する。
• 最近の研究では、LLM が人間よりも約 9 倍の頻度で脆弱性を導入していることが示唆されている。

本研究は、LLM が生成したセキュリティパッチがなぜ失敗するのか、そしてどの程度部分的に成功しているのかを体系的に分析することを目的としています。

2. 手法と実験設定

データセットとモデル

• ベンチマーク: Vul4J（Java のセキュリティ脆弱性 79 件中、再現可能な 64 件を使用）。
• LLM: Gemini 2.0 Flash（ゼロショットプロンプトを使用）。
• 生成数: 各脆弱性あたり 5 つのパッチを生成（計 320 件、1 件除外し 319 件を評価対象）。
• プロンプト: 「セキュリティ専門家として、指定された CWE の脆弱性を修正し、元の機能を保持せよ」という最小限の指示のみ。

評価プロトコル（3 軸評価）

生成されたパッチを以下の 3 つの軸で評価し、5 つのカテゴリに分類しました。

1. コンパイル (Axis 1): Maven/Gradle でのビルド成功。
2. セキュリティ (Axis 2):
   • PoV (Proof-of-Vulnerability) テスト: 脆弱なシステムでは失敗し、修正済みシステムでは成功するエクスプロイトコードの実行。
   • Semgrep: 静的解析ツールによる残余の脆弱性パターンの検出。
3. 機能性 (Axis 3): 開発者テストスイートへの全合格。

評価指標

• セキュリティスコア ($S_{score}$): PoV テストの合格（1/0）と、Semgrep の警告数減少に基づいた重み付けスコア。
• 機能性スコア ($F_{score}$): 通過したテスト数 / 総テスト数。
• セキュリティ修復スコア (SRS): コンパイル成功（$C=1$）かつ、セキュリティと機能性の加重平均（0.5 ずつ）を計算。
  $$SRS = C \times (0.5 \cdot S_{score} + 0.5 \cdot F_{score})$$
  SRS は 0 から 1 の連続値であり、部分的な成功を定量化します。

3. 主要な貢献

1. LLM セキュリティパッチの失敗分類体系の確立: 単なる「成功/失敗」ではなく、失敗のモード（構文エラー、セキュリティ失敗、機能破壊など）を詳細に分類。
2. セキュリティ修復スコア (SRS) の提案: 完全な成功が稀な場合でも、どの程度「部分的に成功」しているかを連続値で測定する新しいメトリクス。
3. CWE 固有の難易度パターンの特定: 脆弱性の種類（CWE）によって修復の難易度が大きく異なることを実証。
4. 実務家への示唆: 具体的な検証ガイドラインの提示。

4. 結果と考察

RQ1: パッチはどのように失敗するか？

• 完全な正解: 319 件中わずか 24.8% (79 件) のみ。
• 支配的な失敗モード: 51.4% (164 件) が「セキュリティと機能性の両方で失敗」しました。
  • 原因は構文エラーではなく、**「意味的な誤解（Semantic Misunderstanding）」**です。LLM は構文的に正しいコードを生成しますが、根本的に誤った修復戦略（例：入力検証の欠落、API 契約の違反）を採用しています。
• 最も危険な失敗: 10.3% (33 件) が「機能は正常だが、依然として脆弱（Insecure & Functional）」なパッチでした。これらは通常の CI/CD パイプラインを通過してしまうため、実運用において最大のリスクとなります。特に「権限管理（CWE-264）」でこの傾向が顕著でした。

RQ2: パッチはどの程度部分的に成功しているか？

• 非対称性: 機能性スコアの平均は 0.832 と高いですが、セキュリティスコアの平均は 0.251 と極めて低いです。
• 二峰性の分布: SRS の分布は二峰性（Bimodal）を示しました。
  • ピーク 1: SRS ≈ 1.0（完全成功、24.8%）
  • ピーク 2: SRS ≈ 0.5（機能は保たれているがセキュリティ失敗、58.9%）
  • ニアミス（0.8 ≤ SRS < 1.0）は 0.3% のみ。
• 示唆: LLM のセキュリティ修復能力は「全か無か（All-or-Nothing）」の性質を持ち、部分的な改善（ニアミス）はほとんど存在しません。したがって、失敗したパッチに対してプロンプトを微調整しても、セキュリティ理解が深まることは期待できません。

RQ3: どの特性が修復の難易度を予測するか？

• CWE による差: 脆弱性の種類が難易度を強く予測します。
  • CWE-835 (無限ループ): 修正率 45%（機械的な修正が可能）。
  • CWE-20 (入力検証): 修正率 0%（ドメイン固有の知識が必要）。
• パッチサイズとの相関: 人間が作成したパッチのサイズと、LLM の成功確率には負の相関（Spearman $\rho = -0.331$）がありました。複雑なパッチほど LLM は失敗しやすいですが、コードの構造的複雑さ（サイクロマティック複雑度など）とは相関しませんでした。
• 結論: 難しさはコードの「構造」ではなく、「何を修正すべきか」という意味論的理解にあります。

5. 意義と示唆

実務家への示唆

• 厳格な検証の必要性: LLM 生成パッチをデプロイする前に、機能テストだけでなく、PoV テストや静的解析によるセキュリティ検証が必須です。
• 脆弱性タイプ別の重点管理: 入力検証や権限管理などの脆弱性タイプでは、LLM パッチが特に信頼できないため、人的レビューを優先すべきです。
• 機能性とのトレードオフの否定: セキュリティを修正するために機能性が損なわれるという仮定は誤りです。両立は可能ですが、LLM はセキュリティ側で失敗する傾向があります。

研究者への示唆

• 意味論的理解の強化: 現在の LLM は構文生成は得意ですが、脆弱性の本質的理解が不足しています。脆弱性固有のコンテキスト（エクスプロイトの説明や修正パターン）を提供する研究が重要です。
• CWE 特化型アプローチ: 脆弱性の種類に応じて異なる修復戦略をルーティングする（例：機械的な修正は LLM、意味論的な修正は人間や別の手法）アプローチが有効です。

結論

本研究は、LLM によるセキュリティパッチ生成が、構文エラーではなく意味論的な誤解によって主に失敗し、機能性は維持されるがセキュリティは修復されない「二極化」した結果を生むことを示しました。SRS という新しい指標により、部分的な成功を定量化できることを実証し、実運用における厳格な検証と、脆弱性タイプに応じた戦略的アプローチの重要性を提言しています。