コード生成AI、偽の『安全なコード例』で攻撃される

『CWE』って何？脆弱性のカテゴリみたいなもの？

CWEは「Common Weakness Enumeration」の略で、ソフトウェアの脆弱性を分類するカタログみたいなものです。単なるカテゴリではなく、業界全体で認識されている標準的なリスト。 例えば、SQLインジェクション、バッファオーバーフロー、認証漏れといった具体的な弱点パターンが、それぞれ番号で登録されている。CWE-89がSQLインジェクション、CWE-120がバッファオーバーフローといった具合ですね。 この論文での攻撃の巧みさは、ここにあります。攻撃者が「CWE-○○の弱点パターン」を意図的にコード例に埋め込むことで、生成AIがそれを参考にして、同じ弱点パターンを持つコードを作り出してしまう。つまり、攻撃者は『どんな脆弱性を仕込むか』をあらかじめ決めて、それに合わせた改ざんコードを用意するわけです。 AIが参考資料から学ぶ仕組み自体は優れているのですが、その参考資料が信頼できるという前提が崩れると、弱点も一緒に学習させられてしまう。業界標準のカタログがあるおかげで、攻撃も「狙い撃ち」しやすくなった側面と言えそうです。

ChatGPT でコード書いてもらってる開発者って、このリスク意識してるの？自分が受け取ったコードが危険かどうか、どうやって確認するの？

多くの開発者は、おそらくこのリスクを意識していないと言えそうです。「AI が出したコード = 参考資料に基づいてるから信頼できる」という思い込みは、けっこう強いから。 ただ現実には、開発チームで「コードレビュー」をしている組織なら、多少の防壁が機能しています。生成AIのコードを誰かが目視で確認する習慣がある場所では、不自然な脆弱性パターンに気づく可能性がある。逆に「AI に書かせたから大丈夫」と検証を軽くしてしまう現場ほど危ないということです。 自分で確認する手段としては、静的解析ツール（コードをスキャンして既知の脆弱性を検出するツール）を通すのが現実的。SonarQube や Veracode といったツールは、この論文で実証されたような典型的なパターンなら捕捉できる可能性が高い。ただし、攻撃者があえて新しい脆弱性タイプを仕込んできたら、ツールが追いつかない可能性も残ります。 つまり、「生成AIを使う = 検証コストが増える」という矛盾が生まれてきた段階に、いま産業全体が突入しているのかもしれません。

コード生成AI は参考資料から学ぶことで精度が上がってきたはずだけど、いつ頃から『その参考資料自体が狙われる』という問題が指摘されるようになったの？

コード生成AIが参考資料を活用し始めたのは、ここ数年のこと。ChatGPT が登場した2022年末以降、こうしたツールが急速に実用化されて、初めて大規模に使われるようになったんですよね。 言い換えれば、「参考資料が狙われる」という問題も、ほぼ同時期に浮上した新しい脅威です。従来は、ローカルの学習データやクローズドな環境で学習するAIがほとんどだったので、攻撃者が外部から参考資料を改ざんするという発想自体が成立しなかった。 ただ、実は2023年くらいから、学習データの毒性化（データポイズニング）という攻撃手法の研究は始まっていました。でも、それは「学習時に悪質なデータを混ぜる」という段階での話。今回の論文が示してるのは、学習後のツールが実運用で外部リソースを参照する瞬間を狙う、という一段階新しい攻撃です。生成AIが黒箱から実用の道具へ移行したからこそ、こういう二次的な脅威が可視化され始めた、と言えそうです。

これって『情報源を信頼する設計の宿命』みたいなこと？つまり、何かを学ぶ・参考にする仕組みは、必ず『参考元を改ざんする攻撃』に弱くなるってこと？

コード生成AIの場合、単なる「情報源への信頼」の問題ではなくて、もっと構造的な脆弱性があるんですよね。 人間がコードを学ぶときは、参考資料を見ても「これ本当に安全？」と疑う余地があります。でもAIは、外部から引っ張ってきたコード例に「安全タグ」が付いていたら、そこを深掘りしない。参考資料の信頼度を判定する仕組みが、AIには備わっていないわけです。 つまり攻撃の本質は「参考元を改ざんする」ことではなく、「AIが参考資料の真正性を検証しない」ことにある。人間の学習なら、複数の情報源を比較したり、実装者の名声を考えたり、社会的な信用を評価する。でもAIの場合、一度参考資料に取り込まれた情報は、ほぼ無条件に活用されてしまう。 論文で成功率が80〜93%だった理由もここです。改ざんが巧妙だったというより、AIが「この脆弱性は本当か」と問い返す能力を持たないから。参考資料の信頼性を多層的に検証する仕組みがなければ、この攻撃はいつまでも有効なのかもしれません。

攻撃者がわざわざこんな巧妙な細工をするメリットは何？被害者のシステム全体にアクセスする直接攻撃より、難しくないの？

攻撃者の視点で考えると、この手法のメリットは「痕跡の曖昧さ」にあります。 システムに直接侵入すれば、ログに痕跡が残る。だけどコード生成AIを経由すれば、脆弱性の原因が「AIの判断ミス」に見えてしまう。開発者も「ChatGPTが出してきたコードだし」と、そこまで徹底的には検証しない可能性がある。実際には攻撃者が細工したコード例が元凶なのに、責任の所在がぼやけてしまう。 もう一つは「スケーラビリティ」です。参考資料に1つ仕込めば、それを使う複数の開発チーム、複数のプロジェクトに自動で広がっていく。狙い撃ちではなく、まき餌のようなやり方。特にオープンソースのコード例や Stack Overflow のような公開サイトに紛れ込ませば、知らず知らずのうちに大量のアプリケーションに脆弱性が入る可能性がある。 だから難しさの質が違うんです。直接攻撃は「破り方」の難度が高いけど、この手法は「検出されにくさ」の難度が高い。検出されなければ、労力は小さくて効果は大きい、という逆転が起きているんだと言えそうです。