OWASP Top 10 2025 / Next Steps X03  

🤖 OWASP Top 10 2025 / Next Steps X03

AIが書いたコードを
信じすぎるという新しいリスク

「動いたから採用」でいいのか。OWASPが2025年版で名指しした
“バイブ・コーディング”の危うさを、実証データと一次情報で。

Vibe Coding スロップスクワッティング AI×セキュリティ 査読論文で裏取り

💡 この記事を3行でいうと

  1. OWASPは2025年版で「AI生成コードへの不適切な信頼(バイブ・コーディング)」を名指ししました。ただし、これはTop 10の本体ではなく「Next Steps(次点)」。この位置づけを間違えている日本語記事がほとんどです。
  2. なぜ本体でないのか。答えは公式に書かれています——「AI生成コードに関連するCVEやCWEがまだ存在しない」から。つまり”軽い”のではなく、”データがまだ追いついていない”だけです。
  3. 実証データは十分に揃っています。AI生成コードの約45%に脆弱性(Veracode)、AIが薦めるパッケージの約2割が実在しない(USENIX査読論文)。「読まずに信じる」姿勢こそが穴になります。
01

📍 まず位置づけ:X03は「11位」ではない

ここを取り違えると、記事も理解も丸ごとズレます。最初に固めます。

🗂

OWASP Top 10 2025 の”本当の形”

2025年版の本体は A01〜A10 の10カテゴリです。ところがその後ろに、「Next Steps(次のステップ)」という付録的なセクションがあり、X01・X02・X03 の3項目が並んでいます。これは「本体入りを検討したが、最終的に入らなかった注目リスク」の控え室です。X03はそのうちの1つ。Top 10の”中”には入っていません。

🗺 全体マップ:本体10カテゴリと「Next Steps」

本体:OWASP Top 10 2025(A01〜A10) A01 アクセス制御の不備 A02 セキュリティ設定の不備 A03 サプライチェーンの不備 ★ A04 暗号化の不備 A05 インジェクション A06 安全性を欠いた設計 A07 認証の不備 A08 完全性の不備 A09 ログとアラートの不備 A10 例外的な状況への対応 ★ ★=2025年版で新設。データ(280万アプリ)から選ばれた8枠+投票2枠 Next Steps(次点・控え室) X01 アプリのレジリエンスの欠如 X02 メモリ管理の失敗(旧バッファオーバーフロー系) X03 AI生成コードへの不適切な信頼=この記事の主役

Q. X03「AI生成コードへの不適切な信頼」は、OWASP Top 10 2025のどこにある?

正解は3番目。X03は本体A01〜A10には含まれず、Next Steps(X01/X02/X03)の1つです。「Top 10入りした」という表現は不正確なので注意してください。
02

⚙ なぜ本体に入れなかったのか

「重要じゃないから外した」ではありません。理由は選び方の仕組みにあります。

OWASP Top 10の本体は、データで決まります。2025年版は13の組織が提供した280万件を超えるアプリのデータと、約17万5千件のCVE(実際に報告された脆弱性)を分析し、「そのタイプの脆弱性を1つ以上持つアプリの割合(発生率)」でランキングして8カテゴリを選びました。残る2枠はコミュニティ投票です。

ここで問題が起きます。AI生成コードのリスクは新しすぎて、まだCVEやCWE(脆弱性の分類番号)として積み上がっていないのです。OWASPはこう明記しています——「現時点では、AI生成コードに関連するCVEやCWEは存在しない。しかし、AIが生成したコードが人間の書いたコードよりも多くの脆弱性を含むことは、広く知られ、文書化されている」。

🎯

「圏外」の正しい読み方

データ駆動の仕組みは「すでに起きて記録が残ったもの」しか本体に入れられません。AIコードの問題は、実害は明らかなのに、統計の形になるのがこれからという段階。だからOWASPは本体に入れる代わりに、Next Stepsで「これは近いうちに来る。今から備えろ」と名指ししたのです。X03は”優先度が低い”のではなく、”計測が追いついていない最前線”です。

🔮

近い将来、独立プロジェクトになるかもしれない

OWASPのコミュニティでは、AI生成コード専用の枠組み(「OWASP Top 10 for AI-Generated Code」)を立ち上げる提案が議論されています(GitHub上の提案段階)。CVEやCWEが蓄積されれば、次回改訂でX03が本体入りする、あるいは独立した基準へ育つ可能性があります。今この記事を読んでおくことは、その”前夜”を押さえることでもあります。

03

🌊 Vibe Codingとは何か

OWASPの公式文書に、生まれて1年もたたない俗語が採用された珍しい例です。

「Vibe Coding(バイブ・コーディング)」は、2025年2月にAI研究者のアンドレイ・カーパシー氏が広めた言葉です。おおまかに言えば「コードの中身を細かく読まず、AIに任せて”雰囲気(vibes)”で開発を進めるスタイル」を指します。プロンプトを投げ、出てきたコードが動けば次へ——という進め方です。この語は2025年のコリンズ英語辞典の「今年の言葉」にも選ばれました。

Vibe Coding自体は、プロトタイプを高速に作る手段としては強力です。問題は「動く」と「安全」はまったく別物だという点。動くコードにも脆弱性は潜みます。そして、中身を読んでいなければ、その脆弱性に気づけません。OWASP X03が問題にしているのは、まさにこの「読まずに信じる」姿勢そのものです。

📝

OWASPが突きつける一文

公式のNext Stepsには、こう書かれています——「あなたが提出するすべてのコードに責任を負うのは、あなた自身です。AIが書いたコードであっても、コミットするすべてのコードを読み、完全に理解している必要があります」。ツールがどれだけ賢くなっても、最終的な責任者は人間である、という当たり前の再確認です。

04

📊 数字で見る:AIコードは本当に危ないのか

「なんとなく危なそう」を、査読論文とベンダー調査の実数に置き換えます。

45%

AI生成コードに
脆弱性が含まれる割合

Veracode 2025(100超のLLM×80タスク)

2.74

XSSの発生率
(対 人間のコード)

Veracode 2025

19.7%

AIが薦めるパッケージが
実在しない割合

USENIX Security 2025(査読)

セキュリティ企業Veracodeが2025年に公開した大規模調査(100を超えるLLMに80種のコーディング課題を解かせたもの)では、AIが生成したコードの約45%が何らかのセキュリティ欠陥を含んでいました。とくにXSS(クロスサイトスクリプティング)対策のタスクでは、安全なコードを書けたのはわずか1割程度にとどまったと報告されています。

そして最も重要なのが、スタンフォード大学の研究(Perry ら、ACM CCS 2023)です。AIアシスタントを使った開発者はより安全でないコードを書いたうえに、自分の書いたコードをより安全だと信じる傾向があった——という結果でした。つまり「危険度が上がるのに、安心感も上がる」という二重の落とし穴です。OWASP X03が”信頼”という言葉を使うのは、この心理を突いているからです。

⚠ 数字の扱いについて

ネット上には「混入率62%」「38万アプリが漏洩」といった刺激的な数字も出回りますが、本記事ではこれらの一次原典を確認できなかったため採用していません。ここで挙げた数値は、いずれも査読論文(USENIX/CCS)または調査手法が公開されたベンダーレポート(Veracode)に出典を限定しています。AI分野は誇張が多いので、数字は必ず出どころを確かめる姿勢が、そのままX03の実践でもあります。

05

🎃 新しい攻撃面①スロップスクワッティング

AIの”幻覚”を、攻撃者が逆手に取る。X03ならではの新しい脅威です。

LLMは、実在しないライブラリ名を、さも本物のように提案することがあります(パッケージ・ハルシネーション)。前述のUSENIX 2025の研究では、16のモデルに57万6千件のコードを生成させたところ、推奨パッケージの19.7%が実在しませんでした。しかも架空の名前の43%は、10回試すと毎回同じものが再現したといいます。つまり「AIが繰り返し薦める、存在しない名前」が予測できてしまうのです。

攻撃者はここに目をつけました。AIがよく幻覚する名前を先回りして本物のレジストリ(npmやPyPI)に悪意あるパッケージとして登録しておく。すると、AIの提案を鵜呑みにした開発者が、そのままインストールして罠にかかります。この手口は「スロップスクワッティング(slopsquatting)」と呼ばれます。よくあるタイプミスを狙う「タイポスクワッティング」の、AI時代版です。

🔗 スロップスクワッティングの流れ

① AIが幻覚 実在しない名前を提案 ② 攻撃者が先回り その名前で悪意パッケージ登録 ③ 開発者が信じる 提案どおりインストール ④ 汚染成立 依存経由でコード実行 AIの”よくある幻覚”が予測可能だから成立する(USENIX 2025)

下は練習です。表示されるパッケージ名が実在するものか、それともAIが幻覚しそうな架空の名前(=スロップスクワッティングの罠になりうる名前)か、直感で当ててみてください。判断の”クセ”に気づくのが目的です。

🧪 ミニ演習:実在?それともAIの幻覚?

パッケージ名を見て、実在するか架空かを選んでください。※架空名はクリックできないテキストです(実際にインストールしないでください)。

準備中…

上のボタンで回答してください。

正解 0 / 挑戦 0

鉄則:AIが薦めたパッケージは、入れる前にレジストリで実在確認

公式のnpm/PyPIページを直接開き、ダウンロード数・メンテナ・公開日・リポジトリの実在を確認してから追加します。「AIが言ったから」でインストールしない。これだけでスロップスクワッティングの大半は防げます。

06

📄 新しい攻撃面②ルールファイル汚染

AIコーディング補助ツールの「設定」そのものが、攻撃経路になります。

CursorやGitHub Copilotのような支援ツールは、プロジェクトごとの「ルールファイル(設定ファイル)」を読んで、コード生成の方針を決めます。2025年3月、セキュリティ企業Pillar Securityが「Rules File Backdoor」という手法を公表しました。このルールファイルに、人間の目には見えない文字(ゼロ幅文字や双方向制御文字)で悪意ある指示を埋め込むと、AIがその指示に従って、バックドア入りのコードを”自然に”生成してしまう、というものです。

怖いのは、汚染された指示がレビューでも見えにくい点です。共有された設定ファイルやテンプレートを取り込んだだけで、以後そのプロジェクトのAI生成コードが静かに汚染され続ける可能性があります。この報告を受けて、GitHubは隠れたUnicodeを含むファイルに警告を出す機能を追加しました。ツール提供側は「AI生成コードのレビュー責任は利用者にある」と回答しており、これもX03の主張と一致します。

他人の設定・テンプレートを鵜呑みにしない

外部から取り込むルールファイル、プロンプトテンプレート、依存READMEなども”入力”です。不可視文字が混じっていないかを確認し、信頼できない出所の設定はそのまま使わない。当サイトのゲーム制作でも、不可視文字(ゼロ幅・Bidi制御)の除去は基本対策として徹底しています。

07

💥 実際に起きた事故

「理論上は危ない」ではありません。もう起きています。

CVE-2025-48757 / CVSS 9.3

Lovable のDB露出

AIコード生成プラットフォーム

Vibe Coding系サービスで作られた170超の本番アプリのデータベースに、匿名で読み書きできる状態だったと報告されました。行レベルのアクセス制御(RLS)が正しく設定されておらず、個人情報が外部から参照可能に。研究者はわずか15行程度のコードで抽出を再現したとされます。

アクセス制御(A01)と接続2025年
設定・認証の不備

Tea アプリの流出

モバイルアプリ

認証・ストレージ設定の不備により、身分証明書や自撮り画像を含む大量の個人データが流出したとされる事案。複数のセキュリティベンダーが、Vibe Coding的な作り方に共通する設定不備のパターンとして分析しています。

設定不備(A02)と接続2025年
🧩

X03は”単独の新種”ではなく、既存カテゴリの”増幅装置”

ここが本質です。Lovableの事故は結局A01(アクセス制御の不備)、TeaはA02(設定不備)。AIは新しい種類の脆弱性を発明したわけではなく、従来からあるA01〜A10の穴を、高速に・大量に量産しているのです。だからX03の対策は「AI特有の魔法の防御」ではなく、Top 10の基本をAI生成コードにも例外なく適用すること——に尽きます。

08

🧭 紛らわしいOWASPの3つを整理

「AI」と「OWASP」が付く資料は複数あります。混同すると迷子になります。

🗂 名前が似ている3つの使い分け

資料対象何のためのものか
OWASP Top 10(Web)2025Webアプリ全般Webアプリの代表的リスク。X03はこの”Next Steps”にいる
OWASP Top 10 for LLM ApplicationsLLMを組み込んだアプリプロンプトインジェクション等、LLMを使うアプリ自体のリスク(LLM01〜)
(提案中)AI-Generated Code版AIが生成したコードX03を発展させた専用枠組みの提案段階

ざっくり:X03=「AIが書いたコードを人間が信じすぎる」問題/ LLM Top 10=「AIを組み込んだアプリ」の問題。別物です。

09

✅ 対策:AI生成コードの受け入れ基準

魔法はありません。「読む・確かめる・記録する」を仕組みにするだけです。

X03の対策は、OWASPの言う「人間の理解責任」を、個人の心がけではなくチームのルールに落とし込むことです。下は、AIが出したコードを本番に入れる前のセルフチェックです(結果は保存されません)。

チェックした項目:0 / 7 ——「AIに任せる」ほど、この7つを仕組みにする価値が上がります。

Q. X03への最も本質的な対策はどれ?

正解は2番目。AIは既存のA01〜A10の穴を量産しているだけなので、特効薬より「基本を例外なく適用する」ことが効きます。全面禁止は現実的でなく、X03も禁止ではなく”理解責任”を求めています。
10

📚 出典と更新履歴

数値・引用は、以下の一次情報を2026年7月に確認したものです。

🔗 主な出典(=一次情報)

  1. OWASP Top 10:2025 – Next Steps(X01/X02/X03) — owasp.org/Top10/2025/X01_2025-Next_Steps/(英語)/日本語版
  2. OWASP Top 10:2025 Introduction(選定方法論) — owasp.org/Top10/2025/0x00_2025-Introduction/
  3. Spracklen et al.「We Have a Package for You!(パッケージ・ハルシネーション)」USENIX Security 2025(査読) — usenix.org(PDF) / arXiv:2406.10279
  4. Perry, Srivastava, Kumar, Boneh(Stanford)「Do Users Write More Insecure Code with AI Assistants?」ACM CCS 2023(査読) — arxiv.org/abs/2211.03622
  5. Veracode「2025 GenAI Code Security Report」(2025年10月) — veracode.com
  6. Pillar Security「Rules File Backdoor」(2025年3月18日) — pillar.security/blog/…
  7. CVE-2025-48757(Lovable のRLS不備、CVSS 9.3) — NVD / CVE
  8. OWASP Top 10 for LLM Applications 2025 — genai.owasp.org
  9. ☆ トレンドマイクロ(日本語)「スロップスクワッティング」解説 — trendmicro.com/ja_jp/research/(二次情報)
  10. IPA「生成AIの利活用と開発におけるセキュリティガイドライン」 — ipa.go.jp/digital/ai/security/

📌 更新履歴・見直し方針

  • 2026-07-24:初版公開。OWASP Top 10:2025 公式(日本語版含む)に準拠。
  • 見直し目安:AI分野は動きが速いため半年ごと、および「OWASP Top 10 for AI-Generated Code」提案の進展時。事例(Lovable等)とツール名(Cursor/Copilot)は経年で古びる前提で、原則パートと事例パートを分けて構成しています。

コメント