「バイブ・コーディング」――AIモデルを使ってコード作成を支援すること――は、多くのチームにとって日常的な開発の一部になっています。大幅な時間短縮になる一方で、AI生成コードを過信してしまい、セキュリティ脆弱性が入り込む余地を生むこともあります。
Intruderの経験は、AI生成コードがセキュリティにどのような影響を与え得るかを示す現実のケーススタディです。何が起きたのか、そして他の組織が何に注意すべきかを紹介します。
AIにハニーポット構築を手伝わせたとき
私たちのRapid Responseサービスを提供するため、初期段階の攻撃（エクスプロイト）試行を収集するよう設計したハニーポットを構築しました。そのうちの1つでは、欲しい動作をそのまま満たすオープンソースの選択肢が見つからなかったため、近ごろ多くのチームがやっていることを行いました。つまり、AIを使って概念実証（PoC）の下書きを作ったのです。
それは隔離環境における意図的に脆弱なインフラとしてデプロイしましたが、それでも展開前にコードの簡単な健全性チェックは行いました。
数週間後、ログに奇妙なものが現れ始めました。攻撃者のIPアドレス配下に保存されるはずのファイルが、代わりにペイロード文字列の名前で現れていたのです。これは、ユーザー入力が意図しない場所に入り込んでいることを明確に示していました。
想定外だった脆弱性
コードを詳しく調べると、何が起きていたのかが分かりました。AIが、クライアントが指定したIPヘッダーを取得し、それを訪問者のIPとして扱うロジックを追加していたのです。
これは、そのヘッダーが自分で管理しているプロキシから来る場合にのみ安全です。そうでなければ、実質的にクライアントの制御下にあります。
つまり、サイト訪問者は簡単にIPアドレスを偽装でき、またヘッダーを使ってペイロードを注入することもできます。これは、私たちがペネトレーションテストでよく見つける脆弱性です。
今回のケースでは、攻撃者は単にヘッダーにペイロードを入れていただけで、それが不自然なディレクトリ名の説明になりました。影響は小さく、完全なエクスプロイトチェーンの兆候もありませんでしたが、攻撃者がプログラムの挙動にある程度影響を与えられる状態ではありました。
もっと悪い結果になっていた可能性もあります。もし別の用途でIPアドレスを使っていたなら、同じミスがローカルファイル開示（Local File Disclosure）やサーバーサイドリクエストフォージェリ（SSRF）につながっていてもおかしくありませんでした。
SASTが見逃した理由
私たちはコードに対してSemgrep OSSとGosecを実行しました。Semgrepはいくつか無関係な改善点を報告したものの、どちらもこの脆弱性を検出しませんでした。これはそれらのツールの失敗ではなく、静的解析の限界です。
この特定の欠陥を検出するには、クライアント提供のIPヘッダーが検証なしで使われていること、そして信頼境界が強制されていないことを、文脈として理解する必要があります。
人間のペンテスターなら明らかな種類のニュアンスですが、レビュー担当者がAI生成コードに少し過度な自信を置くと、簡単に見落とされてしまいます。
AI自動化による油断
航空分野には、自動化を監督することは手作業でタスクを行うよりも認知的負荷が高い、というよく知られた考え方があります。同じ効果がここでも現れたように見えました。
そのコードは厳密な意味では私たちのものではありませんでした――自分たちでその行を書いたわけではないため――動作のメンタルモデルが十分に強固ではなく、レビューの質が落ちました。
ただし、航空との比較はそこまでです。オートパイロットシステムには何十年にもわたる安全工学の蓄積がありますが、AI生成コードにはそれがありません。まだ、頼れる確立された安全余裕が存在しないのです。
これは孤立した事例ではなかった
AIが自信満々に安全でない結果を出したのは、これだけではありません。私たちはGeminiの推論モデルを使ってAWS向けのカスタムIAMロール生成を支援させましたが、それは権限昇格に脆弱でした。問題を指摘した後でさえ、モデルは丁寧に同意したうえで、別の脆弱なロールを生成しました。
安全な設定に到達するまでに4回の反復が必要でした。モデルが自律的にセキュリティ問題を認識した場面は一度もなく、終始人間が舵取りする必要がありました。
経験豊富なエンジニアであれば通常こうした問題を見つけます。しかしAI支援開発ツールは、セキュリティの背景がない人でもコードを作りやすくしており、最近の研究では、こうしたプラットフォームによって導入された脆弱性がすでに数千件見つかっています。
しかし私たちが示したように、経験豊富な開発者やセキュリティ専門家でさえ、AIモデルが自信ありげに見え、第一印象では正しく動作しているように振る舞う場合、欠陥を見落とし得ます。そしてエンドユーザーには、依存しているソフトウェアにAI生成コードが含まれているかどうかを見分ける手段がありません。したがって責任は、コードを出荷する組織に明確にあります。
AIを使うチームへの教訓
最低限として、開発者ではない人やセキュリティ担当ではないスタッフが、AIに頼ってコードを書くことは推奨しません。
また、組織として専門家にこれらのツールの使用を許可する場合でも、この新しい種類の問題がすり抜けないよう、コードレビューのプロセスとCI/CDの検出能力を見直す価値があります。
AIによって持ち込まれる脆弱性は、時間とともにより一般的になると私たちは見ています。
AIの利用が原因だったと公に認める組織は多くないため、問題の規模は報告されているものより大きい可能性が高いでしょう。これが最後の例になることはなく――そして、孤立したものだとも私たちは考えていません。
デモを予約して、侵害に至る前にIntruderがどのように露出（リスク）を発見するのかをご確認ください。
著者
Sam PizzeyはIntruderのセキュリティエンジニアです。以前はリバースエンジニアリングに少し夢中になりすぎたペンテスターで、現在はアプリケーションの脆弱性をリモートで大規模に検出する方法に注力しています。
