LLM-Based コーディングへの提言：危険なサンプル・コードの学習を想定すべきだ

New Research and PoC Reveal Security Risks in LLM-Based Coding

2025/08/28 gbhackers — 2025年8月22日に公開された詳細なブログ記事によると、最近の調査で明らかになったものに、LLM のみを用いて生成されたアプリケーション・コードにおける、深刻なセキュリティ脆弱性の可能性についての指摘がある。この調査が強調するのは、広範なインターネット・データを学習した、つまり、安全ではない可能性のあるサンプル・コードを学習した LLM が、開発者に対して潜在的なリスクを警告することなく、安全が確保されていないパターンを複製していくという問題点である。

長年にわたり、セキュリティ専門家たちは、オンラインで見つかるサンプル・コードは、セキュリティよりもデモンストレーションを優先していると警告してきた。

そして、LLM が大規模に学習／反復する安全ではないスニペットにより、この問題がさらに悪化している。注目すべき事例として、研究者たちが挙げたのは、大手暗号通貨プラットフォームの pay-per-view プラグインのサンプル・コードで発見された脆弱性である。

この脆弱性はサンプル実装のみに存在し、コア・ライブラリには存在しなかったが、本番環境のアプリケーションにコピーされ、セキュリティ・レビューで見過ごされる可能性は否定できない。

研究者によるブログ記事の狙いは、LLM により生成されたクライアント・サイド・コードが、メール送信 API エンドポイントを、ブラウザの JavaScript でダイレクトに公開する様子を実証することにある。

この脆弱なスクリプトは、API URL／入力検証／送信ロジックを、すべてフロント・エンドで定義していた。

const smtp_api = "https://<redacted-domain>/send-email";
function validateForm(name, email, number) {
if (!name || !email || !number) {
alert("すべての必須項目を入力してください。");
return false;
}
return true;
}

async function submitForm(name, email, number) {
const data = { name, email, number, company_email: "<redacted@redacted>", project_name: "<redacted>" };

const res = await fetch(smtp_api, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(data)
});
// …
}

これらの詳細がクライアント側で公開されてしまうと、意図されたワークフロー外でリクエストを作成する攻撃者は、検証を完全に回避できてしまう。

以下の PoC エクスプロイトでは、攻撃シナリオをシミュレートするために、シンプルな cURL コマンドを使用している。

curl -X POST "https://redacted.example/send-email" \
-H "Content-Type: application/json" \
-d '{"name":"Test User","email":"test@example.com","number":"1234567890","country_code":"+91","company_email":"me@example.com","project_name":"Redacted Project"}'

この単純なエクスプロイトが実証するのは、任意のメール・アドレスへのスパム送信／顧客へのフィッシング・メッセージ送信／信頼できる送信者への成りすましなどが可能になることだ。つまり、こうしたサンプル・コードが自動生成されると、さまざまな形の脅威が急速に拡大していく。

この研究者は、ホスティング・プロバイダに対して脆弱性を報告したが、問題のアプリがサードパーティのサンプルであるため、修正は範囲外であると告げられたという。

とはいえ、この事例が浮き彫りにするのは、より広範な問題である。LLM はビジネス・コンテキストと脅威モデリングへの理解が不足しているため、悪用事例や防御設計について独自に判断することができない。したがって、攻撃対象領域を特定し、安全なデフォルト設定を適用するには、人間による監視が依然として不可欠である。

ユーザー組織において、開発ワークフローに AI を統合するケースが増えているが、この調査が強く認識させるのは、セキュリティを後回しにしてはならないことだ。

LLM が生成する脆弱性が、本番環境に到達するのを防ぐ必要がある。そのためには、LLM による支援に対して、人間による厳格なコードレビュー／脅威モデリング／自動セキュリティ・テストを組み合わせることが不可欠である。

この記事が解説するのは、LLM が生成したコードに潜むセキュリティ上の危険性の具体例です。原因となるのは、学習段階で安全性が十分に担保されていないサンプル・コードを取り込み、そのまま再利用してしまうという、いまの LLM に存在する問題点です。事例として取り上げられているのは、メール送信 API をフロント・エンド側で直接呼び出す実装であり、この種のコードを学習する LLM が問題を拡大すると、この記事は指摘しています。よろしければ、LLM で検索も、ご参照ください。