7割が虚偽？AIコード生成が破壊するサプライチェーンセキュリティ
公開日
ChatGPTやGitHub CopilotといったAIコーディング支援ツールは、今や開発に欠かせない存在です。しかし、その圧倒的な利便性の裏で、私たちが築き上げてきたソフトウェアのサプライチェーンそのものを破壊しかねない「見えない脅威」が静かに進行しています。
本記事では、デラウェア大学の研究者たちによる論文「Investigating Security Implications of Automatically Generated Code on the Software Supply Chain」を基に、その衝撃的な実態を解き明かします。結論から言えば、AIが提案するコンポーネントの中には実に7割以上が存在しない「虚偽」のものであるケースも確認されており、無自覚なまま利用すれば、深刻なセキュリティインシデントに直結する危険性があります。
なぜAIは危険なコードを生成するのか？
脅威の根源は、LLM（大規模言語モデル）が持つ3つの根本的な課題にあります。
- ファブリケーション（ハルシネーション）: 事実に基づかない、もっともらしい嘘を生成します。存在しないパッケージ名やライブラリを「それらしく」作り上げてしまうのです。
- ミスリーディング: 一見正確そうでも、実際には既知の脆弱性を含む古い情報に基づいている場合があります。
- 古い学習データへの依存: ある特定の時点のデータで学習しているため、最新のセキュリティ情報が反映されず、時代遅れで危険なコードを生成します。
これらの課題が、実際の開発現場でどのような「罠」となって現れるのか。Stack Overflowから収集した実際の質問に基づく43万件以上のプロンプトを4つの主要LLM（GPT/Llamaシリーズ）に入力した大規模実験の結果を見ていきましょう。
【調査結果①】最も身近な罠「パッケージ・ハルシネーション」
多くの開発者が最初に直面するのが、LLMが存在しないライブラリやパッケージをコード内で参照してしまう「パッケージ・ハルシネーション」です。攻撃者はこの存在しないパッケージを先取りして悪意あるコードと共に公開し、開発者がAIのコードを信じてインストールするのを待ち構えることができます。
▼図表1: 4つのLLMにおけるハルシネーション発生率
上のグラフは、4つのLLMが、存在しないパッケージ、ドメイン、GitHubアカウントを生成してしまう「ハルシネーション」の発生率を示したものです。
棒グラフに注目してください。Package（パッケージ）の項目が、他のDomain（ドメイン）やGitHub Account（GitHubアカウント）に比べて突出して高いことがわかります。パッケージのハルシネーションは平均33%以上という非常に高い確率で発生しており、3回に1回は「嘘のパッケージ」を提案されている計算になります。
「お願い」の仕方で、嘘はさらに増える
さらに厄介なことに、LLMへの「頼み方」一つで危険度は大きく変わります。
▼図表2: プロンプトの種類によるハルシネーション率の変化
このグラフは、LLMへの指示（プロンプト）の内容別に、パッケージ・ハルシネーションの発生率を比較したものです。
左端のOriginal Question（単に問題を質問）に比べ、Single Package（パッケージを1つ提案して）やFive Packages（5つ提案して）と明確に依頼すると、発生率が急激に悪化しているのが一目瞭然です。これはLLMが事実の正確さよりも「ユーザーの要求に応えること」を優先してしまう性質を持っていることを示しています。
【調査結果②】存在するが「脆弱な」コンポーネントという罠
ハルシネーションだけでなく、LLMは実在するものの「既知の脆弱性」を含む危険なコンポーネントを推奨してしまうこともあります。
▼図表3: 脆弱なコンポーネントの検出率
| 脅威 | GPT-4o-mini | GPT-3.5-turbo | Llama-3.1-8b | Llama-3.1-sonar |
|---|---|---|---|---|
| 脆弱な3rdパーティ製コンポーネントのバージョン | 5.52% | 6.46% | 6.97% | 4.58% |
| 脆弱なCI設定 | 2.18% | 1.29% | 0.10% | 0.12% |
この表が示すように、最大で約7%の確率で、脆弱性を持つライブラリがあなたのコードに紛れ込む可能性があります。開発者が気づかぬうちに、アプリケーションにバックドアを仕込んでいるのと同じことになりかねません。
【調査結果③】衝撃の事実：サプライチェーンの心臓部で「7割以上が虚偽」
そして、この研究で最も衝撃的だったのが、ソフトウェアのビルドやデプロイを自動化するCI（継続的インテグレーション）プラグインに関する結果です。
▼図表1（再掲）: 4つのLLMにおけるハルシネーション発生率
先ほどもご覧いただいたこのグラフの折れ線グラフに注目してください。この線はCIプラグイン（Plugin）とそのバージョン（Plugin Ver.）のハルシネーション率を示しています。
結果は驚くべきもので、LLMが提案するCIプラグインの実に70%以上、最大で95.95%が存在しないという驚異的な数値を示しています。ソフトウェア開発の自動化を担う、いわばサプライチェーンの心臓部が、これほど不正確な情報で構成されかねないという事実は、計り知れないリスクです。
▼図表4: CIプラグインのバージョン・ハルシネーションの例
| LLM | プラグイン | 実際のバージョン | ハルシネーションで生成されたバージョン |
|---|---|---|---|
| GPT-4o-mini | akhileshns/heroku-deploy | 3 | 23 |
| GPT-3.5-turbo | ad-m/github-push-action | 4 | 7 |
| Llama-3.1-8b | appleboy/ssh-action | 6 | 12 |
| Llama-3.1-sonar | appleboy/ssh-action | 5 | 10 |
さらにこの表が示すように、バージョン番号も極めて不正確です。実際の最新版とはかけ離れた、存在しないバージョン番号を平然と生成してしまうのです。
開発者はどうすれば身を守れるのか？
これらの脅威に対し、研究ではプロンプトの工夫による防御策「Chain-of-Confirmation（確認の連鎖）」が提案されています。これは、以下の3ステップを踏むことでリスクを低減させるアプローチです。
- 抽出: まずLLMに、生成したコードからパッケージ名を抽出させる。
- 確認: 次に、抽出したパッケージが「実際に存在するか」をLLM自身に確認させる。
- 再生成: 最後に、「存在が確認できたパッケージのみを使用して」再度コードを再生成させる。
この手法により、パッケージ・ハルシネーションの発生率を約半分にまで低減できたと報告されています。
結論：AIは「副操縦士」、鵜呑みは禁物
AIによるコード生成は、開発の生産性を飛躍させる強力なツールです。しかし、それは決して完璧な「自動操縦システム」ではありません。
AIはあくまで 「優秀な副操縦士」 であり、最終的な判断と検証の責任は、機長である開発者自身にあります。AIが生成したコード、特に外部コンポーネントを参照する箇所は、それが本当に存在するのか、安全なものなのかを必ず自身の目で確認する。その一手間が、未来の深刻なセキュリティ事故を防ぐための唯一の方法です。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料: