構築する価値があるなら、保護する価値があります。
Vibe codingは大きな話題となっています。AIによる自動化やコーディング自体は新しいものではありませんが、vibe codingはソフトウェア開発を民主化する可能性を秘めています。自然言語で希望を記述するだけで、残りはLLMが処理します。
Cursor、Copilot in VS Code、WindsurfのようなAI強化型IDEから、Bolt、Lovable、v0のようにコーディングを完全に抽象化するプラットフォームに至るまで、この分野ではすでにツールの爆発的な増加が見られ、今後も指数関数的な成長が続くと予想されます。
AI開発の状況の概要については、AINativeDevをご覧ください
良い結果のみを望みます。
迅速に構築し、「コードの存在すら忘れる」ことができるのは解放感があります。特にプロの開発者でない場合はなおさらです。しかし、vibe codingにおける最大のリスクは、何を知らないのかを知らないことであり、多くの場合、AIが生成したコードが何をするのか理解できない可能性があります。
確かに、期待どおりに動作するかどうかを検証することはできますが、内部で何が起こっているかを知らなければ、手遅れになるまでコードがどのようなリスクを生み出しているか、常に把握できるわけではありません（そして、デバッグはそもそもコードを書くよりもはるかに困難であることはよく知られています）。何かを構築する労力をかけるのであれば、たとえvibe codingでそのプロセスを加速させているとしても、セキュリティインシデントによって後退することは避けたいはずです。
経験豊富な開発者でさえセキュリティに関しては盲点があり、バイブコーディングはソフトウェア開発をより身近にする一方で、SQLインジェクション、パストラバーサル攻撃、悪意のあるアクターに脆弱なシークレットなど、アプリケーションを脆弱性や攻撃にさらすことをより速く、より容易にします。一部のバイブコーディングプラットフォームは脆弱性への対応に努めていますが（v0はLLMコードに対してデフォルトで懐疑的です）、バイブコーディング時のセキュリティギャップという非常に現実的なリスクは依然として存在し、その結果、「バイブコーディング＝Vulnerability-as-a-Service」という皮肉な見方が生まれています。
以下の例をご覧ください。
残念ながら、上記の不運な友人がアプリをシャットダウンしてやり直すことになった明確な理由は一つではありません。彼のAPIキーが漏洩したことは明らかであり、これによりハッカーは彼になりすますことができ、データ、機能、またはリソースにアクセスしたり変更したりできることを意味します。
ここには、不安全なAPIキー管理の落とし穴がいくつもあった可能性があります。アプリケーションへのシークレットのハードコーディング、環境変数ファイルが意図せずサーバーにアップロードされること、またはパストラバーサル脆弱性の被害に遭うこと（Atlassianでも発生しました）。追加のセキュリティチェックとプロセスがなければ、ハッカーやボットがAPIキーに簡単にアクセスできたでしょう。
一般的なセキュリティ脆弱性とリスク
ChatGPTのみを使用している場合でも、Lovableのような専用ツールでvibe codingを行っている場合でも、これらの一般的な種類のサイバー攻撃に対して脆弱です。
クロスサイトスクリプティング（XSS）
クロスサイトスクリプティング（XSS）攻撃は、ユーザーが提供した入力が、表示または処理される前に適切に検証またはサニタイズされていないWebアプリケーションの脆弱性をエクスプロイトします。ハッカーはユーザー入力を介して悪意のあるコードを「インジェクト」し、インジェクトされたスクリプトが実行されると、機密情報にアクセスしたり、被害者（この場合はユーザーの1人）に代わって不正なアクションを実行したりできます。XSS攻撃は、この自己リツイートツイートのように、無害なものに見えることもありますが、ユーザーのデータが漏洩したり、アカウントがハッカーに乗っ取られたりするリスクにさらします。
SQLインジェクション攻撃
XSSと同様に、SQLインジェクション（SQLi）攻撃は、多くの場合、脆弱なユーザー入力フィールドを介して、悪意のあるコードをアプリケーションに注入します。SQLは多くのアプリケーションが基盤となるデータベースを照会するために使用する言語であるため、この種の攻撃により、ハッカーはデータベースを閲覧または変更し、機密データにアクセスしたり、レコードを削除したりすることが可能になります。2017年のEquifaxデータ侵害はSQLインジェクション攻撃の結果であり、Equifax自体が標的とされたわけではなく、同社が依存関係の1つにセキュリティパッチを適用していなかったことが原因でした。
パストラバーサル攻撃
攻撃者はファイルパス入力（通常はURLやファイルパラメータ）を操作して、アプリケーションに非公開のファイルやディレクトリを返させ、アクセス制御を回避し、機密データを含むファイルを読み書きできるようにします。この種の攻撃は、安全でないユーザー入力によっても可能になります。2010年、研究者たちはAtlassianのConfluenceアプリケーションにおけるパス・トラバーサル脆弱性を発見しました。これにより、Confluenceが動作しているユーザーの権限に基づいて、Confluenceを実行しているサーバー上の任意のファイルを取得できる可能性がありました。
シークレット漏洩
パスワード、暗号化キー、APIトークン、デジタル証明書などのシークレットは、悪意のある攻撃者にシステムへの鍵を与えてしまいます。これらの機密データにより、ハッカーはなりすまし、データへのアクセス、コードの改ざんを行うことができます。GitGuardianのState of Secrets Sprawl reportによると、2024年には公共のソースコードリポジトリで驚くべき2300万件のシークレットが発見されました（前年比25%増）。シークレットは、アプリケーションに誤ってハードコードされたり、2025年3月のtj-actions/changed-filesの侵害のような脆弱性を介して公開されることがあります。この侵害では、攻撃者がtj-actions/changed-files GitHub Actionのコードを改ざんし、侵害されたアクションがGitHub ActionsのビルドログにCI/CDシークレットを出力するようにしました。
サプライチェーン攻撃
アプリケーションのコードの85～95%がオープンソースライブラリやプロジェクトによって動いている可能性があります。サプライチェーン攻撃は、特定の種類の脆弱性をエクスプロイトしたり、特定のアプリケーションを標的にしたりするのではなく、多くの企業が依存している基盤となるオープンソースプロジェクトを狙います。上記のEquifaxデータ侵害は、すでに軽減されていたサプライチェーン攻撃の結果でした。これは、依存関係を監視し、セキュリティパッチを迅速に適用することの重要性を示しています。
Vibe codingは、探索や概念実証（PoC）の構築に優れたツールですが、それを実行可能な製品やビジネスに変えることに興味を持った瞬間から、構築したものを保護するために、セキュリティチェックとベストプラクティスを確立したくなるでしょう。
AIにもっと安全なコードを書くように頼むだけではだめですか？
これはもっともな疑問です。AIがデフォルトで安全なコードを書かないことは承知していますが、非常に手軽な改善策として、プロンプトに「and make it secure（安全なものにしてください）」という言葉を文字通り追加するなど、明示的に安全にするよう依頼する方法があります。驚くべきことに、これにより実際に脆弱性の少ないコードが生成されます。
AIに自身のコードをレビューさせ、ハードコードされたシークレットの発見、データが公開されていないことの確認、プロジェクトの脆弱な依存関係のスキャン、入力検証が不十分なユーザー入力フィールド（フォームなど）の特定など、脆弱性やセキュリティギャップを検出させることも可能です。これらの取り組みはすべて、アプリケーションのセキュリティを向上させます。
しかし、AIが生成したコードに潜在的なハルシネーション、脆弱性、その他のセキュリティギャップがないかファクトチェックする目的は、人間の監視なしにAI自身に修正させるのはリスクが高すぎるからです。AIを従来のスキャン方法と統合して機能を強化することは可能ですが、それらを置き換えることはできません（例えば、AikidoはAIを使用してセキュリティアラートを自動トリアージし、修正案を提案します）。
最も優れたソフトウェアエンジニアは、通常、知らないことを素直に認めることができる人々でもあります。AIに自己監視を過度に依存することの問題点は、不確実性を認める代わりに、誤ったことについて自信を持って断言することが珍しくない点です。そのため、アプリケーションのセキュリティ確保においてAIのみに依存することはお勧めしません。
良いニュースは、vibe codingが普及するずっと前から、多くの企業やオープンソースプロジェクトがこれらのセキュリティ問題への対処に専念してきたことです。新しい開発者が学ぶ最大の教訓の1つは、「巨人の肩の上に立つ」ことです。アプリケーションには、認証、暗号化、あるいはユーザーがUIにファイルをアップロードする方法など、機密性が高くミッションクリティカルなコンポーネントが多数存在します。そして、それらをCursorやGPTに構築させることは、
- 製品の差別化にはつながりません
- セキュリティリスクを導入する可能性が非常に高いです
そのような場合、それらの問題の解決策に特化したプロバイダーに頼る方がはるかに優れています。LLMは、ベストプラクティスや問題を最も効率的かつ安全な方法で解決することに特化してトレーニングされているわけではありません。多くの場合、最も洗練された解決策は、独自のものを構築するよりも既存のサービスを利用することです（たとえ重い作業をAIにオフロードするとしても）。
圧倒されてしまい、どこから始めればよいかわからなくなることがあります。より安全に構築を開始できるよう、このチェックリストを作成しました。
レベル0
これらは、できるだけ早く導入すべき基本的なセキュリティ対策です。これらのプラクティスが確立され、プロセスの一部となれば、雰囲気を損なうことなく自由に開発を進めることができます。
Gitのベストプラクティスを導入する
雰囲気でコーディングする際のよくある落とし穴の1つは、新しい機能を追加したり問題を修正しようとする際に、以前のコードを新しいAI生成コードで単純に置き換える方が直感的であることです。これは一時的には機能しますが、最終的には、AIが生成するものが何も役に立たず、以前よりも状況が悪化するという壁にぶつかる可能性があります。
これがバージョン管理の目的です。
Gitのようなバージョン管理は、開発者が互いの作業を上書きすることなくプロジェクトで共同作業を行う方法として登場しました。しかし、単独で開発している場合でも、進捗状況をバックアップする方法として機能し、バグの特定や、問題が発生した際に変更を元に戻すのに役立ちます。より安全に開発を進めるのに役立つ3つの主要なGitプラクティスを以下に示します。
機密ファイル用の.gitignoreファイルを作成する
.gitignoreファイルは、Gitに何を無視するか（つまり、リポジトリにコミットしないか）を指示する単なるプレーンテキストファイルです。通常、Gitにはログのようなコンピューター生成ファイルを無視させたいものです。これらはリポジトリを煩雑にし、アプリケーションに関する情報が含まれており、それが悪用されて侵害される可能性があります。また、.envファイルも無視されるべきです。これには、ハッカーがシステムへのアクセス権を得るために、あなたになりすますために使用する可能性のある、APIキーやパスワードなどの機密性の高い環境変数が含まれています。
明確なコミット履歴を維持する
変更を可能な限り自己完結型に保つことで、バグや脆弱性がいつ導入されたかを特定しやすくなり、他の作業をやり直すことなく元に戻すことが容易になります。さらに一歩進んで署名付きコミットを設定すると、適切な開発者がリポジトリにコードをコミットしていることを検証できます（それがあなた一人である場合でも！）。
機能開発、ステージング、本番環境のブランチを分離する
Gitでのブランチングは、コードの作業、プレビュー、リリースを行うための明確で自己完結型のスペースを作成するのに役立ちます。別ブランチで積極的に新機能を開発することで、未完成、バグのある、または安全でないコードが誤って本番アプリケーションにコミットされるのを防ぐことができます。新しい機能や機能が完全に開発されテストされた後、ステージングブランチは別のセキュリティおよび品質ゲートとして機能し、本番環境にリリースする前に変更をレビューして最終決定することを可能にします。その後、完全にテストされ安定した機能のみが、本番（通常はmainと呼ばれる）ブランチにマージできます。
シークレットをコードから分離する
パスワード、暗号化キー、APIトークン、デジタル証明書などのシークレットは、コードベースへの直接コミットを避けるため、コードとは別に扱うべきです。Aikidoを使用すれば、Cursor IDEからでもコード内のシークレットをチェックできます。
DDoS攻撃からアプリケーションを保護する
分散型サービス拒否攻撃（DDoS）は、標的のサーバー、サービス、またはネットワークを大量のインターネットトラフィックで圧倒することにより、通常のトラフィックを妨害しようとします。これらの攻撃は壊滅的な結果をもたらす可能性があり、CloudFlareやCloudFrontのようなコンテンツデリバリーネットワーク（CDN）と基本的なDDoS保護を統合することで、驚くほど簡単に自身を保護できます。ドメインホスティングプロバイダーの中には、CDNを組み込みサービスとして提供しているところもあります。
認証を自前で実装しない
認証（ログインフローなど）は、アプリケーションの機密性の高いコンポーネントであり、専門家に任せるべきです。パスワードポリシーを強制し、スケールアップする際にアプリケーションにシングルサインオンや多要素認証を簡単に提供する専用ツールを使用することで、ユーザーアカウントと評判を保護できます。
暗号化を自前で実装しない
同様に、暗号化は専門知識であるため、常に確立されたメカニズム、ライブラリ、ツールに依存してください。独自の暗号化を実装したり、完全に理解していないフラグやオプションを使用したりすると、
重大なリスクにさらされます。NaCLのようなライブラリは、選択肢が少なく、適切な選択肢に限定されます。
レベル1
コードを監視するためのCI/CDパイプラインをセットアップします。
テストを含むCI/CDパイプラインを実装することは、アプリケーションコードの組立ラインに品質チェックポイントを追加するようなものです。静的コード分析ツールを統合してStatic Application Security Testing (SAST)を実行し、セキュリティ脆弱性につながる可能性のあるコードの欠陥をスキャンできます。また、Dynamic Application Security Testing（DAST、表面監視と呼ばれることもあります）用のツールを統合して、攻撃をシミュレートし、Webアプリのフロントエンドの脆弱性（開いているポートや無制限のインバウンドトラフィックの検索など）を特定することもできます。
オープンソースDAST: ZAP
オープンソースSAST: Opengrep
依存関係を監視します。
認識しているかどうかにかかわらず、アプリケーションを動かすコードのほとんどは、AIモデルがトレーニングされているオープンソースプロジェクトやサードパーティライブラリから取得されている可能性が高いです。これらが依存関係であり、時にはそれら自体がさらに依存関係を持つこともあり、これらすべてがソフトウェアサプライチェーンを構成します。これらのライブラリのいずれかに単一の欠陥があるだけで、アプリケーション全体が危険にさらされる可能性がありますが、既知の脆弱性について依存関係を監視するための適切なツールを使用することで、リスクを軽減できます。
推奨ツール：Trivy
依存関係にマルウェアがないか確認してください。
同様に、サプライチェーンにはマルウェアを含む悪意のあるパッケージが含まれる可能性があります。攻撃者はコードにマルウェアを侵入させることに成功した後、通常迅速に行動するため、これらは非常に危険です。そのため、迅速に対応する必要があります。Common Vulnerabilities and Exposures (CVE) データベースは遅すぎ、これらの種類の攻撃から保護することはできません。
ツール: Aikido Intel
ロックファイルを使用してサプライチェーンを保護する
ロックファイルを使用しない場合、アプリケーションをビルドするたびに、すべてのオープンソースパッケージの最新バージョンが取り込まれます。ロックファイルは、オープンソースの依存関係の同じバージョンを取り込むことで、再現可能なビルドを可能にします。これにより、依存関係に破壊的な変更があった場合でもアプリケーションの安定性が保たれるだけでなく、依存関係の最新バージョンが侵害された場合のサプライチェーン攻撃からもアプリを保護します。最近の例としては、2025年3月のtj-actions/changed-filesの脆弱性があります。攻撃者がtj-actions/changed-files GitHub Actionのコードを改ざんし、侵害されたアクションがGitHub ActionsのビルドログにCI/CDシークレットを出力させました。
厳格なCSPヘッダーでクロスサイトスクリプティング攻撃を防ぐ
CSPヘッダーは、どの動的リソースの読み込みを許可するかを制御する追加のセキュリティレイヤーを提供することで、一般的なXSS攻撃から保護できます。これにより、攻撃者がウェブページにスクリプトを注入するのを防ぎます。
Webアプリケーションファイアウォールを使用します。
Webに公開されているサーバーを未知のゼロデイ脅威（未知のSQLインジェクションやXSSの脅威を含む）から保護するために、Webアプリケーションファイアウォール（WAF）またはRuntime Application Self-Protection（RASP）を使用します。このツールは、疑わしいまたは悪意のある挙動（インジェクションペイロードなど）を持つユーザーリクエストをスキャンして阻止し、攻撃に対する最後の防衛線として機能します。
優れたツール: AWS WAF Aikido Zen
レベル2
上記のセキュリティ対策が整ったら、セキュリティ体制をさらに強化しましょう。
コンテナのベストプラクティスを実装します。
コンテナは、ソフトウェアをパッケージ化し、あるコンピューティング環境から別の環境に移動しても確実に実行できるようにします。アプリケーションと、ライブラリ、フレームワーク、設定ファイル（サプライチェーン内のすべて）など、必要なすべての依存関係を単一のパッケージにバンドルします。これにより、アプリケーションはデプロイされる環境に関係なく、一貫して実行されます。
デプロイにコンテナを使用している場合、アプリケーションのセキュリティを強化するのに役立ついくつかのベストプラクティスがあります。
Dockerのベースイメージを常に最新の状態に保ちます。
ベースコンテナイメージ（コンテナの構成要素の設計図）に脆弱性があると、アプリケーションが危険にさらされます。ベースイメージのすべてのセキュリティアップデートを定期的にダウンロードしてください。サーバーの場合、HerokuやAWS BeanstalkのようなPaaSプロバイダーにこれを委任できます。
Dockerのセキュリティをスキャンするには、以下を使用します: Syft Grype Trivy
Dockerコンテナを制限された権限で実行します。
権限を制限することで、攻撃者がホストを乗っ取ったり、他のサービスに移動したりすることが難しくなります。Unixシステムでのroot、またはWindowsシステムでのAdministratorやSystemのような特権ユーザーロールでコンテナを実行することは避けてください。
シークレットを保護します
コードからシークレットを分離することは、優れた第一歩です。コンテナを使用している場合、シークレットファイルやその他の機密データが適切に保護されていることを確認する必要があります。これには、シークレット管理ツール（多くのクラウドプロバイダーが独自のツールを提供しています）の使用、Kubernetesを使用している場合はKubernetesシークレットの利用、シークレットの定期的なローテーション、およびシークレットの有効期限の設定が含まれます。
シークレット管理ツール：HashiCorp Vault AWS Secrets Manager Google Cloud Secret Manager
詳細はこちら: コンテナにおけるシークレットの安全な管理: ベストプラクティスと戦略
パッケージのEnd Of Life (EOL)を確認します。
パッケージが古くなりサポートが終了すると、エクスプロイトのリスクが増加します。間もなくEOLを迎えるパッケージは、必ずアップグレードするようにしてください。
あるいは、Aikidoのコンテナスキャン機能で数秒でセットアップすることも可能です。
クラウドアカウントのベストプラクティスを実装します。
開発、ステージング、本番のクラウドアカウントを分離します。
開発、ステージング、本番のGitブランチを分離したいのと同様に、クラウドアカウントについても同じことが言えます。ステージングと本番を分離するためにクラウドアカウント内に仮想ネットワークを作成することも可能ですが、これは成長するにつれて新しい開発者のユーザーアクセス権を継続的に管理することになるため、後々煩雑になる可能性があります。開発、ステージング、本番のインフラストラクチャは、完全に分離されたクラウドアカウントで管理することをお勧めします。すべてのクラウドプロバイダーは統合された請求を提供しているため、管理の手間が一つ減ります。
クラウドポスチャ管理ツールを使用します。
クラウドプロバイダーは非常に多くの機能を提供しているため、リスクにさらすような設定を見落としたり、誤って設定したりすることが容易に起こります。クラウドセキュリティポスチャ管理 (CSPM) ツールを使用して、クラウドの異常をスキャンしてください。
CSPMツール: Cloudsploit AWS Inspector
クラウド予算アラートを有効にします。
クラウドアカウントがハッキングされた場合、誰かがアカウントでビットコインをマイニングしていることを検出する確実な方法の1つは、支出を監視するための予算アラートを設定することです。クラウドプロバイダーはこれに対する組み込みアラートを提供しているはずですが、予算に関する懸念やリスクの高い設定ミスをチェックするために、Aikidoでクラウドスキャンを設定することもできます。
LLMで最も一般的なエクスプロイトを確認します。
LLMを構築するだけでなく、公開製品にLLMを統合しているかもしれません。ユーザーサポートを提供するチャットボットや、オンボーディングを支援するAIアシスタントがあるかもしれません。顧客が何らかの形でLLMとやり取りする場合、顧客をセキュリティリスクにさらさないように、最も一般的なエクスプロイトについてテストすることをお勧めします。
最も一般的なエクスプロイトを確認します: OWASP Top 10 for LLMs
さらに
セキュアな開発ライフサイクルを実装します。
現代のセキュリティプラクティスの大きな部分は、開発ライフサイクルのより早い段階でセキュリティ対策を導入する「シフトレフト」です。これにより、プロジェクトのあらゆる段階で良い習慣を身につけ、問題が実際の脅威となる前に早期に発見できるようになります。これは、このようなセキュリティチェックリストを遵守し、典型的なセキュリティ上の欠陥を熟知してコードレビュー中にそれらに注意を払い、プルリクエストにもセキュリティチェックを実装することを意味します。
詳細はこちら: OWASP Top Ten
詳細はこちら: システム開発ライフサイクルに関するWikipedia記事
誰もがサイバー攻撃の被害者になり得ます。専任のセキュリティ部門を持つ多国籍企業でさえ、依然として侵害に対して脆弱です。vibeコードはデフォルトでは安全ではありませんが、最初からセキュリティのベストプラクティスを採用することで、安心して開発に集中できます。構築しているものが何であれ、その努力は報われるでしょう。
