セキュリティバイブチェックに合格する：バイブコーディングの危険性

導入

Databricksでは、AIレッドチームが新しいソフトウェアパラダイムが予期しないセキュリティリスクをもたらす可能性があるかどうかを定期的に調査しています。最近私たちが特に注視しているトレンドの一つが、「バイブコーディング」、つまり、生成型AIを使ってコードをカジュアルに、迅速に組み立てる方法です。このアプローチは開発を加速させる一方で、手遅れになるまで気づかれない、微妙で危険な脆弱性を生み出す可能性があることも分かっています。

本記事では、レッドチームの取り組みから得られた実例をいくつか紹介し、バイブコーディングがどのように深刻な脆弱性につながるかを示します。また、こうしたリスクを軽減するための実践を促すための方法論についても解説します。

バイブコーディングの失敗：マルチプレイヤーゲーム

バイブコーディングのリスクを探る初期の実験の一つとして、Claudeに三人称視点のヘビのバトルアリーナの作成を依頼しました。このアリーナでは、ユーザーはマウスを使って頭上カメラの視点からヘビを操作します。バイブコーディング手法に従い、モデルにプロジェクトのアーキテクチャをかなり制御させ、各コンポーネントを段階的に生成するようにしました。結果として得られたアプリケーションは意図したとおりに機能しましたが、このプロセスによって重大なセキュリティ脆弱性が意図せず発生し、放置すると任意のコード実行につながる可能性がありました。

脆弱性

Snakeゲームのネットワーク層では、Pythonオブジェクトがpickleを使用してシリアライズおよびデシリアライズされ、これは任意のリモートコード実行（RCE）に対して脆弱であると知られています。その結果、悪意のあるクライアントやサーバーは、ゲームの他のインスタンスで任意のコードを実行するペイロードを作成し、送信することができました。

下記のコードは、Claudeが生成したネットワークコードから直接取り出されたもので、問題点を明確に示しています：ネットワークから受け取ったオブジェクトが、検証やセキュリティチェックなしに直接デシリアライズされています。

このタイプの脆弱性は古典的であり、十分に文書化されていますが、バイブコーディングの性質上、生成されたコードが「そのまま動作する」ように見える場合、潜在的なリスクを見落としやすくなります。

しかし、Claudeにコードを安全に実装するよう促すことで、モデルが積極的に以下のセキュリティ問題を特定し、解決したことを確認しました：

以下のコード抜粋に示すように、データのシリアライゼーションをpickleからJSONへ切り替えることで問題が解決されました。また、サービス拒否攻撃への対応として、サイズ制限も設定されました。

ChatGPTとメモリ破壊：バイナリファイルの解析

別の実験では、ChatGPTに、安全にパースするのが難しいと広く認識されているGGUFバイナリフォーマットのパーサを生成するよう依頼しました。GGUFファイルは、CとC++で実装されたモジュールのモデルの重みを保存します。我々がこの形式を選んだのは、Databricksが以前に公式のGGUFライブラリでいくつかの脆弱性を見つけたからです。

ChatGPTは迅速に動作する実装を生成し、ファイルの解析とメタデータの抽出を正確に処理しました。これは下記のソースコードで示されています。

しかし、詳細に調査したところ、安全でないメモリ処理に関連した重大なセキュリティ上の欠陥を発見しました。生成されたC/C++コードには、チェックされていないバッファの読み取りと型混乱のインスタンスが含まれており、これらが悪用されるとメモリ破壊の脆弱性を引き起こす可能性があります。

このGGUFパーサーでは、チェックされていない入力と安全でないポインタ演算により、いくつかのメモリ破壊の脆弱性が存在します。主な問題は次のとおりです：

1. GGUFファイルから整数や文字列を読み取る際の範囲チェックが不十分です。ファイルが切り捨てられたり、悪意を持って作成された場合、これらはバッファオーバーリードやバッファオーバーフローを引き起こす可能性があります。
2. 安全でないメモリ割り当て、たとえば、検証されていないキー長に1を加えてメタデータキーのメモリを割り当てるなど。この長さの計算は整数オーバーフローを引き起こし、ヒープオーバーフローを引き起こす可能性があります。

攻撃者は、偽のヘッダー、キーまたは値フィールドの極端に大きなまたは負の長さ、および任意のペイロードデータを持つGGUFファイルを作成することで、これらの問題の2つ目を悪用する可能性があります。例えば、キーの長さが0xFFFFFFFFFFFFFFFF（最大の符号なし64ビット値）の場合、チェックされていないmalloc()が小さなバッファを返す可能性がありますが、その後のmemcpy()はそれを超えて書き込むことになり、クラシックなヒープベースのバッファオーバーフローを引き起こします。同様に、パーサーが有効な文字列や配列の長さを仮定し、利用可能なスペースを検証せずにメモリに読み込むと、メモリの内容が漏洩する可能性があります。これらの欠陥は、任意のコード実行を達成するために潜在的に使用される可能性があります。

この問題を検証するために、私たちはChatGPTに、悪意のあるGGUFファイルを作成し、脆弱なパーサーに渡す証拠の概念を生成するように依頼しました。結果として出力されるのは、プログラムがmemmove関数内でクラッシュし、安全でないmemcpy呼び出しに対応するロジックを実行している様子です。プログラムがマップされたメモリページの末尾に達し、それを超えて未マップのページに書き込もうとするとクラッシュします。これは、範囲外のメモリアクセスによりセグメンテーション違反が発生するためです。

再度、ChatGPTにコードの修正方法を尋ねると、以下の改善策を提案してくれました：

次に、我々は更新されたコードを取り、それに概念証明のGGUFファイルを渡し、コードは不正なレコードを検出しました。

再び、根本的な問題はChatGPTが機能的なコードを生成する能力ではなく、バイブコーディングに固有のカジュアルなアプローチが生成された実装に危険な仮定を見落とさせることでした。

セキュリティ対策としてのプロンプト

セキュリティ専門家があなたのコードをレビューして脆弱性がないことを確認することに代わるものはありませんが、いくつかの実用的で低労力の戦略がバイブコーディングセッション中のリスクを軽減するのに役立ちます。このセクションでは、安全でないコードの生成の可能性を大幅に減らすことができる3つの簡単な方法を説明します。この記事で紹介するプロンプトはすべてChatGPTを使用して生成されており、高度なセキュリティの専門知識がなくても、バイブコーディングを行う人なら誰でも効果的なセキュリティ重視のプロンプトを簡単に作成できることを示しています。

一般的なセキュリティ指向のシステムプロンプト

最初のアプローチは、一般的なセキュリティに焦点を当てたシステムプロンプトを使用して、最初からLLMを安全なコーディング行動に向けることです。このようなプロンプトは、基本的なセキュリティガイダンスを提供し、生成されたコードの安全性を向上させる可能性があります。我々の実験では、以下のプロンプトを使用しました：

言語またはアプリケーション固有のプロンプト

プログラミング言語やアプリケーションのコンテキストが事前に分かっている場合、別の効果的な戦略は、LLMに対して言語固有またはアプリケーション固有のセキュリティプロンプトを提供することです。この方法は、手元のタスクに関連する既知の脆弱性や一般的な落とし穴を直接対象とします。特筆すべきは、これらの脆弱性クラスを明示的に認識している必要はなく、LLM自体が適切なシステムプロンプトを生成できるということです。私たちの実験では、以下のリクエストを使用してChatGPTに言語固有のプロンプトを生成するよう指示しました。

セキュリティレビューのための自己反省

3つ目の方法は、コード生成直後に自己反省的なレビューステップを組み込むことです。最初は特定のシステムプロンプトは使用されませんが、LLMがコードコンポーネントを生成すると、その出力がモデルにフィードバックされ、セキュリティ脆弱性を明確に識別し対処します。このアプローチは、モデルの固有の能力を活用して、初めて見落とされた可能性のあるセキュリティ問題を検出し、修正することを可能にします。我々の実験では、元のコード出力をユーザープロンプトとして提供し、以下のシステムプロンプトを使用してセキュリティレビュープロセスをガイドしました：

実証結果：セキュリティタスクにおけるモデルの挙動の評価

各プロンプトアプローチの効果を定量的に評価するために、我々はPurpleLlamaのCybersecurity Benchmarkのテストスイートからのセキュアコーディングベンチマークを使用して実験を行いました。このベンチマークには、バイブコーディングのワークフローに直接関連するシナリオでLLMが不安全なコードを生成する傾向を測定するための2種類のテストが含まれています。

• テストの指示：モデルは明確な指示に基づいてコードを生成します。
• オートコンプリートテスト：モデルは、先行するコンテキストを与えられた後のコードを予測します。

これら両方のシナリオをテストすることは特に有用であり、典型的なバイブコーディングセッションでは、開発者はまずモデルにコードを生成するよう指示し、その後、問題を解決するためにこのコードをモデルに戻すことがよくあります。これは、指示と自動補完のシナリオを密接に反映しています。我々は、Secure Coding Benchmarkに含まれるすべてのプログラミング言語で、Claude 3.7 SonnetとGPT 4oの2つのモデルを評価しました。以下のプロットは、システムプロンプトがない基本シナリオと比較して、各プロンプト戦略による脆弱なコード生成率のパーセンテージ変化を示しています。負の値は改善を示し、プロンプト戦略が不安全なコード生成の率を減少させたことを意味します。

Claude 3.7 Sonnetの結果

Claude 3.7 Sonnetでコードを生成する際、提供された3つのプロンプト戦略すべてが改善をもたらしましたが、その効果は大幅に異なりました：

• 自己反省は全体的に最も効果的な戦略でした。これは、指示シナリオで平均48％、オートコンプリートシナリオで平均50％の不安全なコード生成率を減らしました。Java、Python、C++などの一般的なプログラミング言語では、この戦略は脆弱性の発生率を約60%から80%減少させることが特筆すべき結果でした。
• 言語固有のシステムプロンプトも有意な改善をもたらし、2つの評価設定で平均して37%と24%、不安全なコード生成を減らしました。ほぼすべてのケースで、これらのプロンプトは一般的なセキュリティシステムプロンプトよりも効果的でした。
• 一般的なセキュリティシステムプロンプトは、平均で16％と8％の改善を提供しました。しかし、他の2つのアプローチの効果が大きいことを考えると、この方法は一般的には推奨される選択肢ではありません。

Self Reflection戦略は脆弱性の大幅な減少をもたらしましたが、LLMにそれが生成する各個のコンポーネントをレビューさせることは時には困難な場合もあります。そのような場合、Language-Specific System Promptsを活用することが、より実用的な代替手段となるかもしれません。

GPT 4oの結果

• 自己反省は再び全体的に最も効果的な戦略であり、指示シナリオで不安全なコード生成を平均30％、オートコンプリートシナリオで51％削減しました。
• 言語固有のシステムプロンプトも非常に効果的であり、両シナリオを通じて不安全なコード生成を平均で約24%減少させました。注目すべきは、この戦略がGPT 4oの指示テストで自己反省を上回ることが時々あったことです。
• 一般的なセキュリティシステムプロンプトはGPT 4oとClaude 3.7 Sonnetでより良いパフォーマンスを発揮し、指示とオートコンプリートのシナリオでそれぞれ平均13％と19％の不安全なコード生成を削減しました。

全体的に、これらの結果は、LLMでコードを生成する際のセキュリティ結果を改善するための実用的で効果的なアプローチとして、ターゲット指向のプロンプトが明らかに有効であることを示しています。プロンプトだけでは完全なセキュリティソリューションにはなりませんが、コードの脆弱性を有意に減らし、特定の使用ケースに応じて簡単にカスタマイズまたは拡張できます。

セキュリティ戦略がコード生成に与える影響

これらのセキュリティに焦点を当てたプロンプト戦略の適用による実際のトレードオフをよりよく理解するために、私たちはLLMの一般的なコード生成能力に対するその影響を評価しました。この目的のために、我々はHumanEvalベンチマークを利用しました。これは、LLMが自動補完のコンテキストで機能的なPythonコードを生成する能力を評価するために設計された広く認識されている評価フレームワークです。

上記の表は、セキュリティプロンプト戦略ごとのHumanEval成功率のパーセンテージ変化を、基準（システムプロンプトなし）と比較して示しています。Claude 3.7 Sonnetについては、3つの緩和策すべてがベースラインのパフォーマンスを一致させるか、わずかに改善しました。GPT 4oについては、セキュリティプロンプトがパフォーマンスをやや低下させましたが、Python特有のプロンプトは基準の結果と一致しました。それでも、脆弱なコード生成の大幅な削減と比較してこれらの差は比較的小さいため、これらのプロンプト戦略を採用することは実用的で有益です。

エージェンティックなコーディングアシスタントの台頭

開発者の増加数は、従来のIDEを超えて新しいAIパワードの環境に移行しており、深く統合されたエージェント型の支援を提供しています。Cursor、Cline、Claude-Codeなどのツールは、この新たな波の一部です。彼らは、リンター、テストランナー、ドキュメンテーションパーサー、さらにはランタイム分析ツールを統合し、静的なコパイロットモデルよりもエージェントのように動作するLLMを通じてすべてを調整します。

これらのアシスタントは、あなたの全コードベースについて推論し、インテリジェントな提案を行い、リアルタイムでエラーを修正するように設計されています。原則として、この相互接続されたツールチェーンはコードの正確性とセキュリティを向上させるべきです。しかし、実際には、我々のレッドチームのテストでは、これらのアシスタントが複雑なロジックを生成またはリファクタリングしたり、入出力ルーチンを処理したり、外部APIとインターフェースを持つときに、特にセキュリティ脆弱性が依然として存在することが示されています。

私たちは、以前の分析と同様のセキュリティに焦点を当てたテストでCursorを評価しました。ゼロから始めて、Claude 4 Sonnetに次のように促しました：「CでGGUFフォーマットの基本的なパーサーを書いてください。メモリからファイルをロードまたは書き込む能力を持たせてください」Cursorは自動的にウェブをブラウズしてフォーマットの詳細を収集し、要求通りにGGUFファイルのI/Oを処理する完全なライブラリを生成しました。結果は、エージェントフローなしで生成されたコードよりもはるかに堅牢で包括的でした。しかし、コードのセキュリティ姿勢をレビューしたところ、以下に示すread_str()関数に存在するものを含む、いくつかの脆弱性が特定されました。

ここでは、str->n 属性がGGUFバッファから直接取得され、検証なしにヒープバッファを割り当てるために使用されます。攻撃者は、このフィールドに最大サイズの値を供給することができ、その値が1増えると、整数オーバーフローによりゼロに戻ります。これにより、malloc()が成功し、最小の割り当て（アロケータの動作による）を返すことになりますが、その後のmemcpy() 操作により、クラシックなヒープベースのバッファオーバーフローが発生します。

緩和策

重要なことに、この記事の初めに探った同じ緩和策：セキュリティに焦点を当てたプロンプト、自己反省ループ、アプリケーション固有のガイダンスは、これらの環境でも脆弱なコード生成を減らすのに効果的でした。スタンドアロンのモデルでバイブコーディングを行っているか、フルエージェントIDEを使用しているかに関わらず、出力を保護するためには意図的なプロンプトと生成後のレビューが必要です。

自己反省

Cursor IDE内での自己反省のテストは簡単でした：私たちは単に以前の自己反省プロンプトを直接チャットウィンドウに貼り付けました。

これにより、エージェントはコードツリーを処理し、脆弱性を検索した後、特定された脆弱性を反復的に修正するようになりました。以下のdiffは、このプロセスの結果を、先ほど議論した脆弱性との関連で示しています。

.cursorrulesを活用してデフォルトでセキュアなコード生成を実現

強力ですが、あまり知られていないCursor機能の一つが、.cursorrulesのサポートです。この設定ファイルを使用すると、開発者はコーディングアシスタントのカスタムガイダンスや行動制約を定義できます。これには、コードの生成やリファクタリングの方法に影響を与える言語固有のプロンプトが含まれます。

この機能がセキュリティ結果に与える影響をテストするために、我々は.cursorrulesファイルを作成し、上記の我々の以前の作業に従ってC特有のセキュアコーディングプロンプトを含めました。このプロンプトは、安全なメモリ処理、境界チェック、信頼できない入力の検証を強調しました。

プロジェクトのルートにファイルを配置し、CursorにGGUFパーサをゼロから再生成するように促したところ、元のバージョンに存在した多くの脆弱性が予防的に回避されることがわかりました。特に、以前にチェックされていなかった値（例：str->n）が使用前に検証され、バッファの割り当てがサイズチェックされ、安全でない関数の使用がより安全な代替品に置き換えられました。

比較のために、ファイルから文字列型を読み取るために生成された関数をここに示します。

この実験は重要な点を浮き彫りにしています：安全なコーディングの期待を直接開発環境にコード化することで、Cursorのようなツールはデフォルトでより安全なコードを生成することができ、リアクティブなレビューの必要性を減らすことができます。これはまた、この投稿の広範な教訓を強調しています。つまり、意図的なプロンプトと構造化されたガードレールは、より洗練されたエージェントワークフローでも効果的な緩和策であるということです。

しかし、興味深いことに、上記の自己反省テストをこの方法で生成されたコードツリーに対して実行したところ、Cursorは生成時に見落とされた一部の脆弱なコードを依然として検出し、修正することができました。

セキュリティツール（semgrep-mcp）の統合

多くのエージェントコーディング環境は現在、開発プロセスとレビュープロセスを強化するための外部ツールの統合をサポートしています。これを実現するための最も柔軟な方法の一つは、Model Context Protocol（MCP）を通じて行うことです。これはAnthropicが導入したオープンスタンダードで、LLMがコーディングセッション中に構造化されたツールやサービスとインターフェースを持つことを可能にします。

これを探求するために、我々はSemgrep MCPサーバーのローカルインスタンスを起動し、それを直接Cursorに接続しました。この統合により、LLMは新しく生成されたコードに対して静的解析チェックをリアルタイムで呼び出すことができ、安全でない関数の使用、チェックされていない入力、安全でないデシリアライズパターンなどのセキュリティ問題を浮き彫りにしました。

これを達成するために、我々は以下のコマンドでローカルサーバーを実行しました：`uv run mcp run server.py -t sse` そして、以下のjsonをファイル~/.cursor/mcp.json:に追加しました。

最後に、.customrulesを作成しました。プロジェクト内のファイルには、次のプロンプトが含まれています：“semgrepツールを使用して、生成されたすべてのコードのセキュリティスキャンを実行する”。その後、私たちはGGUFライブラリを生成するための元のプロンプトを使用し、下のスクリーンショットで見ることができるように、Cursorは必要に応じて自動的にツールを呼び出します。

結果は有望でした。Semgrepは、私たちのGGUFパーサーの初期のバージョンでいくつかの脆弱性を正常にフラグしました。しかし、注目すべきは、semgrepによる自動レビュー後も、自己反省的なプロンプトを適用することで、静的解析だけではフラグされなかった追加の問題が発見されたことです。これには、整数オーバーフローやポインタ算術の微妙な誤用に関するエッジケースが含まれており、これらはコードとコンテキストのより深いセマンティック理解を必要とするバグです。

この二層アプローチ、自動スキャンと構造化されたLLMベースの反省を組み合わせることは特に強力でした。これは、Semgrepのような統合ツールがコード生成中のセキュリティの基準を引き上げる一方で、ロジック、状態の仮定、または微妙なメモリ動作を含む脆弱性を全て捉えるためには、エージェントプロンプト戦略が不可欠であることを示しています。

結論：バイブだけでは不十分

バイブコーディングは魅力的です。それは速く、楽しく、そしてしばしば驚くほど効果的です。しかし、セキュリティに関しては、直感やカジュアルなプロンプトだけに頼るのは十分ではありません。AIによるコーディングが一般的になる未来に向けて、開発者は、ネットワーク化されたシステム、管理されていないコード、または特権を持つコードを構築する際に、特に意図的にプロンプトを行うことを学ばなければなりません。

Databricksでは、生成AIの力に楽観的ですが、リスクについても現実的に考えています。コードレビュー、テスト、セキュアなプロンプトエンジニアリングを通じて、我々はバイブコーディングを我々のチームとお客様にとってより安全にするプロセスを構築しています。業界全体にも同様のプラクティスを導入し、スピードがセキュリティを犠牲にしないよう努めることを推奨します。

Databricksレッドチームの他のベストプラクティスについて詳しく知りたい方は、サードパーティのAIモデルを安全にデプロイする方法やGGML GGUFファイル形式の脆弱性についてのブログをご覧ください。