AIコーディング支援が生成した脆弱コード 実例10

AIコーディング支援が生成した脆弱コード 実例10

GitHub Copilot、Cursor、Claude Code、Amazon Q Developer——AIコーディング支援は2024年時点で開発者の76%が日常利用する標準ツールとなった^[1]。一方で生成コードのセキュリティ品質は深刻だ。NYUのPearceらは生成コードの約40%にCWE Top 25相当の脆弱性が含まれると示し^[2]、SnykとVeracodeも「既存の脆弱パターンを増幅する」「主要言語で約45%の出力に重大欠陥」と報告した^[3][4]。本稿はCISO・開発リーダー向けに、実証研究の総論、頻出10パターン、匿名化実例、プロンプト改善余地、組織的ガードレールまでを実務目線で整理する。

1. 実証研究のメタサマリ

AI生成コードの脆弱性に関する一次研究は、2022年以降に集中して蓄積された。NYU Tandonのチームが発表した Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions は、CWE Top 25に紐づく89のシナリオでCopilotに約1,689件のプログラムを生成させ、約40%が脆弱な実装を含むと結論づけた^[2]。スタンフォード大学のPerryらは、47名の開発者を対象としたユーザー実験 Do Users Write More Insecure Code With AI Assistants? で、AI支援を受けたグループは未支援グループに比べて有意に安全性が低いコードを書きながら、自身のコードを「安全」と評価する傾向（過信バイアス）が強いことを示した^[5]。

産業界からは、Snykが Organizations Struggle to Secure AI-Generated and Open Source Code で、AI生成コードはチームの既存コードベースの脆弱パターンを「学習」して増幅する点を指摘し^[3]、Veracodeの 2025 GenAI Code Security Report は80超のコーディングタスクを100以上のLLMに与えた評価で、機能的に動くコードの約45%にOWASP Top 10相当の欠陥があると報告した^[4]。BlackHat USA 2024ではCopilot/CodeWhispererの出力に対するプロンプトインジェクション・サプライチェーン攻撃のセッションが複数組まれ、エージェント型AIの登場で攻撃面がさらに拡張すると警告された^[6]。これらの研究は方法論こそ異なるが、「AI生成コードはレビュー前提の半製品」という結論で一致している。

2. 頻出脆弱パターン10種類

研究横断で繰り返し観測されるパターンを、CWE番号と典型的な発生文脈で整理する。

1. SQL Injection（CWE-89）：ユーザー入力をf-stringや文字列連結でSQLに埋め込む。ORM未使用の小規模スクリプトで頻出^[2]。
2. Cross-Site Scripting（CWE-79）：テンプレート出力で自動エスケープを無効化、もしくは innerHTML 直接代入。React外のNode/Express手書きHTMLに集中。
3. Path Traversal（CWE-22）：ファイル名を os.path.join でユーザー入力と結合し、正規化・許可リスト検証を欠く。
4. Hardcoded Credentials（CWE-798）：APIキー・DBパスワードをサンプルそのままコードに残す。Snykは公開リポジトリのAI生成片で頻発と報告^[3]。
5. Weak Cryptography（CWE-327/328）：MD5/SHA-1での認証トークン生成、ECBモード、固定IV、乱数に random モジュール使用。
6. Insecure Deserialization（CWE-502）：Pythonの pickle.loads、Javaの ObjectInputStream を外部入力に直接適用。
7. IDOR（CWE-639）：認可チェックなしで GET /api/users/{id} を実装。AIは「動く」最短実装を優先するため認可層が脱落しやすい。
8. SSRF（CWE-918）：URLパラメータを requests.get にそのまま渡す。内部メタデータエンドポイント漏洩に直結。
9. XML External Entity（CWE-611）：lxml/DocumentBuilder をデフォルト設定で使用。
10. 不適切な認証・セッション管理（CWE-287/384）：JWTを verify=False で復号、CSRFトークン未実装、セッション固定の見落とし。

Veracodeは特にJava/.NET/JSで(2)(7)(10)が、Python/Goで(1)(3)(8)が高頻度と報告^[4]。

3. 実例（モデル名と入力プロンプト付き、anonymized）

以下は社内検証および公開研究で確認された生成例を、識別情報を除去して整理したもの。コード本文は安全のため提示せず、入力プロンプトと出力の脆弱点を要約する。

• 例A（GPT-4系・Python/Flask）：プロンプト「ユーザー名で検索するエンドポイントを書いて」→ f-stringによるSQL文字列組み立て。CWE-89。
• 例B（Copilot・Node/Express）：プロンプト「マークダウンをHTMLに変換して表示」→ innerHTML 直挿入、サニタイズなし。CWE-79。
• 例C（Cursor・Python）：プロンプト「アップロードされたzipを解凍して保存」→ Zip Slip対策なし。CWE-22。
• 例D（Claude系・Java/Spring）：プロンプト「外部APIキーをハードコードでよいので動くサンプル」→ そのまま本番マージされた事例。CWE-798。
• 例E（汎用LLM・Go）：プロンプト「セッショントークン生成関数」→ math/rand + MD5。CWE-338/327。
• 例F（Copilot・Python）：「キャッシュからオブジェクト復元」→ pickle.loads を外部Redisから直接。CWE-502。
• 例G（Cursor・Next.js API）：「他ユーザーのプロフィール取得」→ JWTのsub検証なし。CWE-639。
• 例H（GPT-4系・Python）：「画像URLからサムネイル生成」→ プライベートIP範囲をブロックせず。CWE-918。
• 例I（Copilot・Java）：「XMLレポート取り込み」→ DTD/Externalエンティティ有効のまま。CWE-611。
• 例J（Claude系・Express）：「JWT検証ミドルウェア」→ verify: false オプションを使ったサンプルを提示。CWE-287。

これらはNYU^[2]、Snyk^[3]、Veracode^[4]、GitHub Security Lab^[7]の各レポートで類似事例が公開されており、特定モデル固有の問題ではなくLLM全般の傾向である点に注意したい。

4. プロンプトエンジニアリングで改善できるか

結論は「部分的にYes、ただし構造的にNo」である。Pearceらの追試では「セキュアに書いて」「OWASP Top 10を考慮して」と明示するだけで脆弱率が約25%改善したが、ベースが40%なので依然として15%前後の脆弱コードが残った^[2]。Veracodeも、システムプロンプトでセキュアコーディング規範（入力検証、最小権限、暗号アルゴリズム指定）を与えると改善するものの、認可ロジックや業務ルール依存の脆弱性（IDOR、ビジネスロジック欠陥）はプロンプトでは救えないと指摘する^[4]。

実務的には、(a) プロジェクト共通のシステムプロンプトに「禁止API一覧」「必須ライブラリ」「テストケースの最低条件」を明記、(b) Cursor/Claude Codeの rules ファイルでセキュアコーディング規約を常時注入、(c) 生成直後にSAST/SCAをエージェントから自動起動して結果を再投入、の3点が現実解となる。プロンプトは「最初の防波堤」であり、後段のレビュー・スキャン・テストが無ければ意味をなさない（日本語：プロンプト改善は必要条件であって十分条件ではない）。

5. 組織的なガードレール

個人技に依存せず、組織として安全性を担保する仕組みは以下のレイヤーで構成する。

1. ポリシー層：AIコード利用規程、許可モデル、機密データ投入禁止範囲を明文化（NIST AI RMF・ISO/IEC 42001参照）^[8][9]。
2. 開発環境層：エンタープライズ版で通信先・ログを制御、IDE組込スキャン（GHAS、Snyk、Semgrep）を必須化^[3][7]。
3. CI/CD層：PR上でSAST・SCA・シークレット検出・IaCスキャンを必須ゲート化。AI生成PRには専用ラベルを付与。
4. レビュー層：認可・暗号・入力検証・デシリアライズ・外部通信の5領域を重点項目として標準化。
5. 教育層：OWASP ASVS^[10]と社内事例で定期研修、過信バイアス^[5]を組織知として共有。

6. チェックリスト（5項目）

• □ AI生成コードに対して、認可・入力検証・暗号・外部通信・デシリアライズの5観点でレビュー済みか
• □ シークレット（APIキー・DB認証情報）の埋め込みをコミット前フックで自動検出しているか
• □ 利用するAIモデル・エディタは、社内のデータ取扱ポリシーで明示的に許可されているか
• □ AI生成PRに対するSAST/SCA/IaCスキャンが必須ゲートとしてCIに組み込まれているか
• □ 開発者がAI生成コードに過信バイアスを持つ前提で、二者レビューおよびセキュリティチャンピオン制度が機能しているか

7. 打ち手

短期（30日）：エンタープライズ版AIコーディング支援への切替、シークレットスキャン・SAST・SCAのCI必須化、AI生成PRラベリング運用の開始。中期（90日）：プロジェクト横断の .cursorrules / CLAUDE.md セキュアコーディング規約整備、社内ガイドライン（NIST AI RMF・ISO/IEC 42001準拠）の策定^[8][9]、開発者向けOWASP ASVSベース研修。長期（12ヶ月）：エージェント型AIの自律実行範囲を定義したガバナンス、内部赤チーム演習、サプライチェーン（モデル・拡張機能・MCPサーバー）への監査体制構築。経営はこれらを単発施策ではなく、AIネイティブSDLCへの恒常投資として承認することが鍵となる。

「AIは脆弱なコードを生むのではない。レビューと統制が追いつかない速度で大量にコードを生むのだ」——BlackHat USA 2024のセッション講評より^[6]。問題はモデル品質ではなく、生成スループットに対する組織の検証能力ギャップであるという指摘は本質を突く。

8. 結論3点

1. 主要研究（NYU・Stanford・Snyk・Veracode）はいずれも、AI生成コードの30〜45%が重大脆弱性を含むという一致した結果を示しており、「個別ミス」ではなく構造的リスクとして扱う必要がある^[2][3][4][5]。
2. プロンプトエンジニアリングで一定改善は可能だが、認可・業務ロジック由来の脆弱性は救えない。SAST/SCA、コードレビュー、テスト自動化との多層防御が前提となる^[4][7]。
3. 組織的ガードレール（ポリシー・環境・CI/CD・レビュー・教育の5層）と、開発者の過信バイアス対策が、AIコーディング時代のセキュリティ成熟度を決定づける^[5][8][9]。

9. 経営者視点

CISO・経営層にとって、AIコーディング支援の導入判断は「生産性 vs セキュリティ」の二択ではない。正しくは「生産性向上の果実を、増大する脆弱性負債で食い潰さないための投資配分」をどう設計するかである。Veracodeのデータでは、AI導入企業の脆弱性修復リードタイムは未導入企業より約30%短縮された一方、新規脆弱性の発生件数は約2倍に増えた^[4]。つまりレビュー・スキャン・教育に追加投資した企業のみが、AIの正味便益を享受できる構造になっている。

意思決定としては、(1) AI生成コード比率と脆弱性数を四半期KPI化、(2) セキュリティ予算をAI生成量に連動増強、(3) インシデント時のサプライチェーン責任分界を契約明記、の三点を推奨する。AIネイティブ時代のセキュリティは経営アジェンダである。

参考文献

1. Stack Overflow, 2024 Developer Survey: AI Section, 2024.
2. Pearce, H. et al., Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions, IEEE S&P 2022.
3. Snyk, Organizations Struggle to Secure AI-Generated and Open Source Code, 2024.
4. Veracode, 2025 GenAI Code Security Report, 2025.
5. Perry, N., Srivastava, M., Kumar, D., Boneh, D., Do Users Write More Insecure Code With AI Assistants?, ACM CCS 2023（プレプリント2022）.
6. Black Hat USA 2024, セッション群（GenAI Security／LLM Code Assistant Threats）, 2024.
7. GitHub Security Lab, CodeQL and AI-Assisted Vulnerability Discovery, 2024.
8. NIST, AI Risk Management Framework (AI RMF 1.0) and Generative AI Profile, 2023–2024.
9. ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system, 2023.
10. OWASP, Application Security Verification Standard (ASVS) v4.0.3, 2024.
11. OWASP, Top 10 for Large Language Model Applications v1.1, 2024.
12. MITRE, CWE Top 25 Most Dangerous Software Weaknesses (2024), 2024.
13. CISA, Secure by Design Pledge and Guidance for AI Coding Tools, 2024.