技術要約：メタモルフィック・テスティングとアソシエーション・ルール・マイニングを用いた、LLM生成コードの横断的セキュリティ分析

問題提起

大規模言語モデル（LLM）は、セキュリティ脆弱性を包含するコードを頻繁に生成する。先行研究では、LLMが生成するコードがしばしば不安全であることが確立されているが、既存の評価手法は、脆弱性を個別の欠陥として扱う傾向がある（例：SQLインジェクションをバッファオーバーフローとは別に分析する）。このようなアプローチは、ソフトウェア・セキュリティの**横断的な性質（cross-cutting nature）**を見落としている。すなわち、認証、資格情報管理、入力バリデーション、およびメモリ安全性における失敗は、同一のアーティファクト内で併発することが多い。その結果、従来の手法では、これらの脆弱性がどのようにクラスター化するかを診断したり、どのプロンプト特性が広範かつ体系的なセキュリティリスクを駆動しているのかを特定したりすることができない。

手法

著者らは、メタモルフィック・テスティング（MT）とアソシエーション・ルール（AR）マイニングを統合し、LLM生成コードにおけるセキュリティ失敗を検出し、診断し、説明するための4フェーズのフレームワークを提案している。

1. データ生成（フェーズA）： 本研究では、18のCommon Weakness Enumeration（CWE）カテゴリをカバーする148個のユニークな自然言語プロンプトからなるLLMSecEvalベンチマークを利用する。これらのプロンプトを5つのオープンソースモデル（Qwen3-Coder, Qwen2.5-Coder, DeepSeek-Coder, CodeGemma, Gemma4:e4b）に対してそれぞれ5回ずつ実行し、3,700個のコードスニペット（PythonおよびC）を生成した。
2. メタモルフィック判定（フェーズB）： 著者らは、主要なCWEカテゴリを網羅する**9つのセキュリティ指向メタモルフィック関係（MR）**のカタログを定義した。これには、SQLインジェクション（CWE-89）、XSS（CWE-79）、コマンドインジェクション（CWE-78）、パス・トラバーサル（CWE-22）、認証バイパス（CWE-862）、ハードコードされた資格情報（CWE-798）、弱い暗号化（CWE-327）、バッファオーバーフロー（CWE-120）、および整数オーバーフロー（CWE-190）が含まれる。
   • LLMベースの判定器（Claude Sonnet 4.6）が、各スニペットをこれらのMRに対して評価する。
   • 各MRについて、判定器は適用可能性、判定（違反/パス/N/A）、および根拠を提示する。
   • このプロセスにより、行がスニペットを、列がMRを表すバイナリ違反行列が構築される。
3. アソシエーション・ルール・マイニング（フェーズC）： 違反行列は、頻出する共違反パターンを発見するためにAprioriアルゴリズムを用いて処理される。ルールは支持度（support）、信頼度（confidence）、およびリフト（lift、リフト値が1より大きい場合は統計的独立性を超えた正の関連を示す）に基づいて評価される。このステップにより、「横断的」な脆弱性のクラスターを特定する。
4. プロンプトレベルのリスク分析（フェーズD）： 著者らは、特定された違反パターンを、構造的メトリクス、トピックキーワード（例：データベース、認証、メモリ）、セキュリティ意識に関するフレーズ、およびマルチトピックの複雑性を含むプロンプトの特徴と相関させる。また、脆弱性がプロンプト固有のものか、あるいはモデル依存のものかを判断するために、モデル間の整合性を測定する。

ベースライン： 本アプローチは、4つの静的解析ツール（CodeQL, Bandit, Flawfinder, Semgrep）およびLLMSecEvalベンチマークに含まれるセキュアなコードサンプルと比較される。

主な貢献

1. セキュリティ指向MRカタログ： LLM生成コードの検証に特化して設計された、主要なCWEカテゴリを網羅する9つのメタモルフィック関係の定義と適用。
2. 横断的構造診断： ARマイニングをMRの結果と統合することで、セキュリティの失敗が孤立した欠陥ではなく、構造化されたクラスターを形成していることを明らかにした。
3. プロンプトレベルのリスク分析： 共違反クラスターを特定のプロンプト特性と結びつける新しい分析手法により、どのトピックが広範な不安定性を駆動するかを特定した。
4. 大規模な実証的評価： 5つの多様なオープンモデルから得られた3,700個のスニペットを用いた包括的な評価を行い、横断的な脆弱性の蔓延度合いと性質に関する証拠を提供した。

主要な結果

脆弱性の蔓延度

• 生成された全スニペットの**68.8%**が、少なくとも1つのMRに違反していた。
• 適用可能なスニペットの中で、**ハードコードされた資格情報（MR6）およびコマンドインジェクション（MR3）**が最も頻繁に見られる失敗であった（それぞれ79.1%および74.4%）。
• **SQLインジェクション（MR1）**は違反率が最も低く（11.5%）、LLMがパラメータ化クエリのパターンを部分的に内面化していることを示唆している。
• モデルの性能： DeepSeek-Coder (6.7B) は最も脆弱なコード（違反率73.8%）を生成し、Gemma4:e4b (4.5B) は最も安全なコード（65.1%）を生成した。注目すべきは、モデルの規模と安全性に線形な相関は見られなかった点である。最大のモデル（Qwen3-Coder, 30B）が最も安全であったわけではない。

検知の有効性

• MRベースのアプローチは、脆弱なスニペットの**68.8%**を検知した。
• 対照的に、4つの標準的なSASTツールの連合（CodeQL, Bandit, Semgrep, Flawfinder）が検知できたのはわずか**34.2%**であった。
• SASTツールは、認証バイパス（検知率0%）やハードコードされた資格情報（651個中44個のみ検知）といったセマンティックな違反の検知に失敗した。

横断的共違反パターン (RQ2)

ARマイニングにより44個のアソシエーション・ルールが特定され、2つの主要な脆弱性クラスターが明らかになった：

1. 認証–資格情報–暗号化クラスター： 認証バイパス（MR5）、ハードコードされた資格情報（MR6）、および弱い暗号化（MR7）を含む、密接に結合したグループ。
   • 主要な知見： ルール XSS ∧ WeakCrypto ⇒ HardCred は、信頼度82.5%、リフト値3.23を示した。
   • ハードコードされた資格情報と認可チェックの欠如は、最も頻繁な共違反ペアであった（226スニペット）。
2. 入力処理–メモリ安全性クラスター： XSS、パス・トラバーサル、およびバッファオーバーフローを連結するもの。
   • 主要な知見： XSS ∧ PathTrav ⇒ BuffOvf （信頼度 63.0%、リフト値 2.04）。

• クラスター間の架け橋： ルール AuthByp ∧ BuffOvf ⇒ XSS (信頼度 33.3%) はこれら2つのクラスターを繋いでおり、一部のプロンプトが認証とメモリ安全性の両方のドメインにまたがる失敗を同時に引き起こすことを示している。

プロンプトレベルの駆動要因 (RQ3)

• 予測因子： データベース関連のプロンプトが、全体的な脆弱性の最も強力な予測因子であった (r = 0.52)。次いで認証トピックであった (r = 0.43)。
• クラスターの特異性： データベースおよび認証のキーワードは、クラスター1を強く予測したが、クラスター2は予測しなかった。逆に、File I/Oのキーワードは、クラスター2の唯一の予測因子であった (r = 0.31)。これは、総数による分析では見逃される関係である。
• セキュリティ意識： セキュアなコードを明示的に要求すること（例：「secure」「sanitize」などのキーワードの使用）は、より安全な出力との相関を示さなかった (r = -0.04)。
• モデル間の整合性： 5つのモデルのうち、**65.5%**のプロンプトにおいて、モデル間で違反ステータスの一致が見られた。高リスクなプロンプト（両方のクラスターを誘発するもの）は、低リスクなプロンプトよりも、データベースのキーワードを含んでいる確率が14.2倍高く、認証のキーワードを含んでいる確率が6.8倍高かった。

意義と主張

本論文は、LLMによる不安全なコード生成は、単なる独立した欠陥の集合ではなく、構造化された、プロンプトに条件付けられた現象であると主張している。

• 包括的なセキュリティ失敗： 強固な横断的クラスター（例：認証バイパス、ハードコードされた資格情報、および弱い暗号化の三位一体）の発見は、LLMがセキュリティに関する包括的なモデルを欠いていることを示唆している。LLMは、SQLクエリをパラメータ化する手法（低いSQLi率）を学習している一方で、そのクエリに必要な資格情報をハードコードすることを避けること（高いHardCred率）には失敗している可能性がある。
• プロンプト駆動型リスク： 高いモデル間の一致性（65.5%）は、脆弱性がモデルのアーキテクチャよりも、主にプロンプトの内容によって駆動されていることを示している。これは、単純に同程度のサイズのモデルを切り替えるよりも、プロンプトエンジニアリングや学習データに焦点を当てた緩和策の方が効果的である可能性を示唆している。
• 実用的な示唆：
  • クラスターを考慮した検証： 開発者は「クラスターベース」のレビュー戦略を採用すべきである。すなわち、ある脆弱性（例：ハードコードされた資格情報）を検知した場合は、同じクラスターに属する関連する脆弱性（例：弱い暗号化）の即時チェックをトリガーすべきである。
  • ターゲットを絞った介入： 自動化ツールは、特定の脆弱性クラスターを予測するために、特定のトピックキーワード（例：データベース ＋ ファイルI/O）に基づいてプロンプトをフラグ立てすることができる。
  • 表面的な指示の限界： セキュリティを意識したフレーズと安全な出力との間に相関がないことは、現在のLLMが表面的なセキュリティ指示に反応しないことを裏付けており、生成後の検証が不可欠であることを示している。

著者らは、本フレームワークが単純な検知から構造的な診断、およびプロンプトレベルの説明への転換を可能にし、セキュリティ失敗の横断的な性質に関するデータ駆動型の洞察を通じて、より安全なLLM支援プログラミングの基礎を提供するものであると結論づけている。