半年ほど前の記事にはなりますがCSETが”Cybersecurity Risks of AI-Generated Code”というレポートを出していたので自分用にメモです。
セキュリティリスクの文脈ではありますが、単純にコード生成させた時の品質リスクとしても興味深いレポートです
結論：AIコード生成のここがヤバい
- CSETの調査で、AIが生成したコードの検証失敗率（バグが見つかった割合）は平均48%
- 完全に安全だと検証されたコードは、全体のわずか 約30%
- 多くの開発者が 「AIのコードは人間より安全だ」と誤解（ある調査では76%）、これが危険な脆弱性を見過ごす原因になり得る
- 検出されたバグには、バッファオーバーフローやNULLポインタ参照など、深刻な脆弱性につながるものが多数含まれていた
AIコード生成に潜む3つの主要リスク
レポートでは、AIコード生成モデルに関連するリスクを、大きく3つのカテゴリに分類しています 。
- 安全でないコードの生成: モデルが、脆弱性を含むコードを生成してしまうリスク 。
- モデル自体の脆弱性: モデル自体が、悪意ある攻撃や操作の対象となるリスク 。
- 下流（将来）への影響: AIが生成したコードが将来のモデルの学習データとなり、新たな問題を生むフィードバックループなどのリスク 。
リスク1：AIは「安全でないコード」を生成する
「AIが書くコードは、人間が書くより安全かもしれない」と期待する声もありますが、現実はそう甘くありません。
多くの研究が、AIコード生成モデルは脆弱性を含むコードを頻繁に出力することを示しています 。ある研究では、GitHub Copilotが生成したプログラムの約40%に、MITREの「最も危険なソフトウェアの弱点Top 25」に含まれる脆弱性が見つかったと報告されています 。
なぜ安全でないコードが生まれるのか？
- 学習データの問題: モデルは、脆弱性を含む大量のオープンソースコードを学習しています 。学習データに含まれる脆弱性が、生成されるコードに「漏れ出す」のです 。
- 機能性とセキュリティのトレードオフ: ある研究では、コーディング能力が高いモデルほど、安全でないコードを生成しやすい傾向があることが示唆されています 。これは、モデルのトレーニングが機能性を優先し、セキュリティを二の次にしている可能性があることを意味します 。
- 自動化バイアス: 開発者が「AIが生成したから大丈夫だろう」と思い込み、コードレビューを怠ってしまう「自動化バイアス」も深刻な問題です 。ある調査では、技術者の76%が「AIのコードは人間より安全だ」と回答しており、この思い込みが危険な脆弱性を見過ごす原因となり得ます 。
リスク2：モデル自体が攻撃される
AIモデルは、コードを生成するだけでなく、それ自体が攻撃の標的にもなります 。
*CSETによるコード生成モデル開発ワークフローとサイバーセキュリティ上の意味合い *
- データ汚染（Data Poisoning）攻撃: 攻撃者が、悪意のあるコードや脆弱なパターンを含むデータを学習データに紛れ込ませる攻撃です 。これにより、モデルは意図的に危険なコードを生成するよう仕向けられてしまいます 。
- 間接プロンプトインジェクション: モデルが外部のWebサイトなどを参照する機能を持つ場合、その参照先に悪意のある指示（プロンプト）を埋め込むことで、ユーザーの意図しない危険なコードを生成させることができます 。
【CSET評価実験】5つのLLMはどれだけ危険なコードを生成したか？
レポートでは、この問題をより具体的に調査するため、5つのLLMを用いて評価実験を行っています 。
-
対象モデル:
- GPT-4
- GPT-3.5-turbo
- Code Llama 7B Instruct
- WizardCoder 7B
- Mistral 7B Instruct
-
評価方法:
- C言語で脆弱性を引き起こしやすい67個のプロンプトを使用 。
- 生成されたコードを、静的解析ツール「ESBMC」で検証し、バグの有無を確認 。
衝撃的な評価結果
結果は驚くべきものでした。
- 検証失敗率は平均48%: 全モデル平均で、生成されたコードの**48%**に、ESBMCが検出可能なバグ（脆弱性につながる可能性のある欠陥）が含まれていました 。
- 完全に安全なコードは約30%のみ: すべての検証をパスした「安全なコード」は、全体の約30%に過ぎませんでした 。
- 深刻なバグが多数: 検出されたバグの多くは、NULLポインタのデリファレンス、バッファオーバーフロー、メモリリークといった、深刻なメモリ関連の脆弱性でした 。これらは、プログラムのクラッシュや、攻撃者による任意コード実行につながる可能性のある危険なものです 。
*モデルごとのESBMC検証ステータス。赤色の「VERIFICATION FAILED」がバグが検出されたコードの割合を示す *
この実験は、意図的にバグを誘発しやすい状況設定で行われているため、通常利用時の数値を直接示すものではありません 。しかし、AIモデルが介入なしでどれだけ安全でないコードを生成しうるか、その「上限」を大まかに示すものと言えるでしょう 。
私たち開発者はどう向き合うべきか？
このリスクに対して、レポートはいくつかの重要な視点を提供しています。
- 既存のセキュリティ対策を徹底する: AI生成コードは全く新しい脅威というより、既存のソフトウェアサプライチェーンリスクの一部と捉えるべきです 。NISTのサイバーセキュリティフレームワークのような、既存のセキュアな開発プラクティスを、AIが生成したコードにも例外なく適用することが重要です 。
- 責任のシフト: コードの安全性を確保する責任を、個々の開発者にだけ押し付けるべきではありません 。AI開発者やツール提供者は、学習データの健全化や、安全なコード生成を促すモデル設計（セキュア・バイ・デザイン）に責任を持つべきです 。
- 評価軸の見直し: 現在のモデル評価は、HumanEvalのような「機能性」を測るベンチマークに偏りがちです 。これが結果的に、セキュリティを軽視したモデル開発を助長している可能性があります 。機能性だけでなく、セキュリティに関するベンチマークもリーダーボードなどで明示的に評価されるべきです 。
まとめと感想
- AIは、脆弱性を含むコードを頻繁に生成する可能性があるね
- AI生成コードをそのまま使うことは市場リリースする様なソフトではまぁやめた方がいいでしょうね (検証用や自社で使う業務サポートならまだしも)
- 製品としてリリースするような場合は 人間が書いたコード以上に厳格なレビュー を徹底しようね
上記リスクを加味したうえで下記の記事も非常に良い記事となっています
Views: 0
