技術的概要：LLM 生成コードのセキュリティ：比較分析

問題定義

ソフトウェア開発における大規模言語モデル（LLM）の急速な普及は、ソフトウェアセキュリティに関する重大な懸念をもたらしている。開発者が生産性の向上と学習の加速のために AI ツールを活用する一方で、これらのツールが重要なセキュリティ脆弱性を含むコードを生成するリスクが高まっている。過去の研究では、開発者が自らのコードと比較して、AI 生成コードのセキュリティに対して過信を示す傾向があることが示されている。主要な技術組織を含む本番環境において AI 生成コードが使用されているにもかかわらず、異なる人気 LLM によって生成されたコードのセキュリティ態勢に関する包括的な比較実証分析は欠如している。本論文は、現在の AI コード生成ツールに関連するセキュリティリスクを評価し、異なるモデルが脆弱性生成においてどのように比較されるかを明らかにするという喫緊のニーズに対応するものである。

手法

著者らは、7 つの人気 LLM によって生成されたコードのセキュリティを評価する実証研究を実施した。対象モデルは Claude 3、Perplexity AI、OpenAI GPT-4o、Google Gemini、Phind-70B、Amazon CodeWhisperer、IBM watsonx である。

実験設計

1. データセットの選択: 本研究では、MITRE によって特定されたトップ 25 の共通弱点（CWE）のうち 12 種類に対して脆弱性を持つ Python コードを生成するように設計された 81 の自然言語（NL）プロンプトのコレクションである LLMSecEval データセットを利用した。プロンプトは、セキュリティの欠陥を明示的に言及することなく（例：検証要件を指定せずにファイルアップロード機能の作成を依頼するなど）、典型的な開発者の対話をシミュレートするように選択された。
2. コード生成: 研究者らは、7 つの LLM すべてに同一の 81 のプロンプトを入力してコードスニペットを生成させた。4 つのツールは API を介して自動化でアクセスされ、残りの 3 つは手動でプロンプトが実行された。
3. 脆弱性の検出: 脆弱性を特定するためにハイブリッドな静的解析アプローチが採用された。
   • CodeQL: GitHub のオープンソース静的解析クエリを使用して、CWE のサブセットをスキャンするために使用された。
   • GPT-4o: CodeQL クエリでカバーできない残りの CWE を検出するために使用された。著者らは、CWE-306、CWE-434、CWE-522 などの脆弱性を高信頼度で検出するために、特定のプロンプトエンジニアリング技術（「CWE 検出器」としての役割を定義し、指示を強化する）を採用した。
4. 重大度評価: 脆弱性は、GitHub の重大度評価アプローチ（NVD（国家脆弱性データベース）からの CVSS スコアと CodeQL データを集約したもの）に基づき、重大度（Critical、High、Medium、Low）に分類された。

主要な結果

本研究は、567 のコードスニペット（81 のプロンプト × 7 モデル）を分析し、995 の脆弱性を特定した。

脆弱性の普及状況

• 普遍的な脆弱性: 7 つの LLM はすべて、脆弱性を含むコードを生成した。
• 重大度: 特定された脆弱性の大部分は、Critical（33%） または High（65%） の重大度であった。
• スニペットのリスク: 生成されたすべてのコードスニペットの 73% 以上 が少なくとも 1 つの脆弱性を含んでいた。7 つのツールのうち 6 つでは、スニペットの 85〜90% が脆弱であった。
• ツールの比較:
  • Claude 3 は、173 と最も多い総脆弱性数を生成した。
  • Amazon CodeWhisperer は、98 と最も少ない総脆弱性数を生成し、脆弱なスニペットの割合も 73% と最も低かった。
  • IBM watsonx は、総数が 120 と低かったにもかかわらず、コード行数あたりの脆弱性発生率が最も高く、Critical 重大度の脆弱性の割合（すべての Critical 発見事項の 18.6%）も最も高かった。

一般的な脆弱性

分析は、特定の反復的な問題を浮き彫りにした。

• CWE-200（機密情報の露出）: 最も頻繁な脆弱性（381 件）であり、主に Flask アプリケーションでの デバッグモードの有効化 またはスタックトレースの露出によって引き起こされた。
• CWE-522（不十分な保護された認証情報）: 210 件で、プレーンテキストでのパスワード保存、ソルトの欠如、またはパスワード入力への input() 関数の使用が含まれることが多かった。多くのモデルは SHA-256 をハッシュに使用したが、著者らはその速度からパスワード保存には推奨されないことを指摘している。
• CWE-434（制限のないファイルアップロード）: 130 件で、コードがファイルの内容や構造を検証せず、拡張子のチェックのみに依存していた。
• CWE-798（ハードコードされた認証情報）: ソースコードに直接埋め込まれた認証情報の 82 件。

コード品質に関する観察

• 機能性対セキュリティ: 本研究は、モデルがセキュリティよりも機能性を優先する傾向があると指摘した。例えば、watsonx は os.system を直接呼び出す簡潔なコード（7 行）を生成し、コマンドインジェクションを招いたのに対し、CodeWhisperer は入力サニタイズを含むより冗長なコード（43 行）を生成した。
• セキュリティの誤った安心感: 一部のケースでは、モデルがセキュリティ上の問題があるコードを生成しながらも、その不安全性を認めるコメント（例：「#これは非常に不安全性が高い」）を追加したが、それでも脆弱なコードを主要な解決策として出力した。

主要な貢献

1. 比較評価: 本論文は、標準化されたデータセットを使用して、7 つの異なる人気 LLM によって生成されたコードのセキュリティを比較分析した最初の研究である。
2. ハイブリッド検出手法: 著者らは、CodeQL 静的解析と LLM ベースの検出（GPT-4o）を組み合わせた手法を開発し、静的解析単独よりも広範な CWE をカバーできるようにした。
3. リスクの実証的証拠: 本研究は、最先端モデルによって生成された本番準備完了コードにおける重大および高重大度の脆弱性の高い普及率を定量化し、新しいモデルが本質的により安全なコードを生成するという仮説に挑戦している。
4. 単純な修正の特定: 著者らは、モデルの動作における特定かつ単純な変更が脆弱性発生率を劇的に低下させる可能性があることを特定した。例えば、デバッグモードをデフォルトで無効化し、SHA-256 の代わりに推奨されるパスワードハッシュアルゴリズム（Argon2id や bcrypt など）を使用することで、特定された脆弱性の大部分を排除できる。

意義と主張

本論文は、現在の LLM 生成コードのセキュリティ状態が「驚愕すべき」ものであり、これらのツールが生成する脆弱コードの量が多いため、ソフトウェアセキュリティにとっては「祝福」ではなく「呪い」である可能性があると主張している。

著者らは以下を論じている。

• セキュリティは暗黙的ではない: 開発者にセキュリティを手動で検証させたり、安全なコードを明示的にプロンプトさせたりすることに依存することは非現実的である。なぜなら、ほとんどの開発者は深いセキュリティ専門知識を持たず、効率を求めているからである。
• モデルアーキテクチャの変更が必要: 本研究は、ソフトウェアセキュリティの原則を LLM のトレーニングデータとモデルアーキテクチャに直接統合する緊急の必要性を浮き彫りにしている。セキュリティは、ユーザーのプロンプトに依存するオプション機能ではなく、デフォルトの制約であるべきである。
• 開発者の責任: ツールは改善されているが、「開発者はループ内に留まったまま」であり、デフォルトで不安全性であることが多いコードを検証することを強いられている。本論文は、セキュリティの原則をモデル自体に明示的に統合しない限り、AI の普及が進むにつれて脆弱なコードの蔓延は続くと示唆している。

著者らは結論として、LLM は生産性の向上をもたらすものの、その現在の出力は、モデル開発者と広範なソフトウェアエンジニアリングコミュニティの双方から即座の注意を必要とする重大なセキュリティリスクを伴うと述べている。