技術要約：バイブ・コーディング（Vibe Coding）とウェブアプリケーションのセキュリティ

問題提起

自然言語による記述から実行可能なウェブアプリケーションを生成する、大規模言語モデル（LLM）の急速な採用（「バイブ・コーディング」と呼ばれる手法）は、重要なセキュリティ上の決定（認証、入力処理、アクセス制御）を、主に機能的な正当性に最適化されたモデルに委ねることになる。実践者がプロンプトに明示的なセキュリティ要件を付加することも可能だが、そのような「セキュリティを意識したプロンプト（security-aware prompting）」が、ベースラインのプロンプトと比較して、生成されたコードのセキュリティ態勢を意味のあるレベルで改善するかどうかは、依然として未解決の問いである。既存の文献では、軽量な脆弱性のヒントがほとんど影響を与えないとする研究もあれば、反復的な洗練が時に重大な脆弱性を増加させることを示す研究もあり、見解が分かれている。本研究では、タスク、モデル、環境を一定に保ち、プロンプトのみを変化させた状態で、展開可能なアプリケーション全体というレベルでの制御された比較が欠如している。

手法

本研究では、セキュリティ要件の影響を分離するために、**ツイン・プロンプト設計（twin-prompt design）**を採用する。

• コーパス： 機能的に異なる6つのウェブアプリケーション（Python/Flask、Python/FastAPI、JavaScript/Expressにまたがる）を生成した。各アプリケーションは2回ずつ作成され、計12個のプログラムが得られた。
• プロンプトのバリエーション：
  • バリアントA（ベースライン）： 機能、エンドポイント、データモデルを記述した中立的な仕様であり、セキュリティに関する言及はない。
  • バリアントB（セキュリティ意識型）： バリアントAとバイト単位で同一であるが、OWASP Top 10 (2021) から派生した一般的なセキュリティ要件を含むセクションが付加されている。このセクションはアプリケーションに依存せず、チューニングもされていない。
• 生成の制約： すべてのコードは Claude Code（Claude Opus 4.8 モデルを使用）によって生成された。すべての生成は、単一の非反復的なラウンドで行われた。カスタム指示、自己批判ループ、または判定用モデルは使用していない。生成アーキテクチャは、「ワンステップ」の実践的なワークフローを表現するために、意図的に最小限とした。
• コントロール（制御変数）：
  • コンテナ構成の違いが結果を混乱させないよう、すべてのバリアントに対して同一の、セキュリティに中立なDockerfileを使用した。
  • 生成後に手動での編集は行っていない。
  • 両方のバリアントが仕様を満たしていることを確認するため、機能的等価性をスモークテストにより検証した。
• 分析パイプライン： 脆弱性を検出するためにマルチメソッド・アプローチを用いた：
  1. 静的解析 (SAST): Bandit, ESLint, Semgrep。
  2. 依存関係解析 (SCA): pip-audit, npm audit。
  3. 動的解析 (DAST): OWASP ZAP (パッシブ、アクティブ、APIスキャン) および Nikto。
  4. 手動テスト： sqlmap やカスタムスクリプトを用いた、セマンティクスに依存する弱点（例：IDOR、ビジネスロジックの悪用、トークン偽造）に対するターゲットテスト。
• データの集約： 249個の生のツール検出結果を正規化し、脆弱性クラスごとに重複を排除した後、手動レビューを経て75個の確定した検出結果（うち10個は偽陽性）を作成した。

主な貢献

1. 再現可能なコーパス： 12個のLLM生成アプリケーション（6組のペア）と、完全かつ透明な分析パイプラインを含むデータセット。
2. 検証済み検出結果データセット： OWASP Top 10 および CWE にマッピングされた、重複排除済みの75個の確定した脆弱性データセット。
3. 記述的エビデンス： モデルやタスクを変化させるベンチマークとは対照的に、シングルショットの生成プロセスにおけるセキュリティ意識型プロンプトの効果に関する経験的な観察。
4. 手法の妥当性確認： LLM生成コードの脆弱性を検出する上での、SAST、DAST、および手動テストの相補性の実証。

結果

• 脆弱性の減少： セキュリティ意識型バリアント（B）は、すべてのアプリケーションにおいてベースライン（A）と比較して、確定した検出結果が少なかった。
  • 総検出数： バリアントAで51、バリアントBで24。
  • アプリあたりの平均： Aは8.5、Bは4.0。
• 深刻度の推移： バリアントBには、**Critical（緊急）またはHigh（高）**の深刻度を持つ確定した検出結果は存在しなかった。2個のCriticalおよび11個のHighの検出結果は、すべてバリアントAにのみ存在した。残りのバリアントBの検出結果は、主に低深刻度の設定に関する問題であった。
• 脆弱性クラス： 最も一般的な確定検出結果は、セキュリティ設定の不備（A05）であり、次いでアクセス制御の不備（A01）および識別と認証の失敗（A07）であった。
• 検出の相補性： 3つの検出手法は、互いに大きく重複していた。
  • 28個の検出結果はSASTのみで発見された。
  • 24個はDASTのみで発見された。
  • 11個は手動テストのみで発見された。
  • 複数の手法によって裏付けられたのは、わずか12個であった。
  • 重要な知見： 最も深刻な問題（ベースラインにおけるアカウント乗っ取りを可能にするJWT偽造）は、手動テストのみによって検出された。自動スキャナーは見逃していた。逆に、最も深刻な自動アラート（SQLインジェクション）は、偽陽性であった。
• 言語間の違い： Pythonアプリケーションは、JavaScript（9.0）よりも高い平均検出数（14.25）を示したが、著者はこれはアプリケーション数の不均衡や機能的な違いによるものであり、決定的な言語レベルの結論を出すことはできないと注記している。

意義と主張

本論文は、統計的に確立された因果効果を提供することではなく、パイプラインを確立し検証することを目的とした予備的研究として位置づけている。著者は、サンプルサイズが小さいこと（6つのアプリケーション、各バリアントにつき1回の生成実行）から、これらの結果は統計的な有意性の証明ではなく、記述的な観察であると明示している。

主な意義は、単一の生成プロセスにおいて、ベースラインの仕様に単純な、チューニングされていないセキュリティプロンプトを付加するだけで、すべてのCriticalおよびHighの深刻度の脆弱性を排除できるという観察にある。これは、軽量なヒントは効果がないとする一部のベンチマーク文献とは対照的であるが、著者はこれを、ここでの使用されたOWASP由来の要件セクションが、他の研究における簡潔な「ナッジ（促し）」よりも包括的であったことによるものとしている。

また、本研究は、最も深刻な真の脆弱性が自動ツールでは不可視であった一方で、最も深刻な自動アラートが偽陽性であったことから、手動テストおよびマルチメソッド分析の決定的な必要性を強調している。著者は、セキュリティ意識型プロンプトは有望ではあるものの、今後の課題として、生成実行ごとの変動性への対処、複数のモデルへの拡張、およびシングルショットのプロンプトと反復的な洗練アーキテクチャの比較を挙げている。