作る価値があるなら、確保する価値がある。
バイブ・コーディングが話題を呼んでいる。AIによる自動化やコーディングは目新しいものではないが、バイブ・コーディングはソフトウェア開発の民主化を約束する。
Cursor、VS CodeのCopilot、WindsurfのようなAIを強化したIDEから、コーディングを完全に抽象化するプラットフォーム(Bolt、Lovable、v0など)まで、この分野のツールはすでに爆発的に増えており、今後も指数関数的な成長が続くと予想される。
チェックアウト AINativeDevによるAI開発の概要
良い雰囲気だけを求める
しかし、バイブ・コーディングの最大のリスクは、自分が何を知らないのかがわからないということだ。
確かに、あなたが期待することを実行することを検証することはできますが、フードの下で何が起こっているのかを知らなければ、手遅れになるまで、コードがどのようなリスクを生み出しているのかを常に知ることはできません(そして、デバッグは、最初に実際にコードを書くよりも難しいことで有名です)。せっかく何かを作ろうとしているのなら、たとえバイブ・コーディングによってそのプロセスを加速しているとしても、セキュリティ・インシデントによって挫折するのは一番避けたいことだ。
バイブコーディングは、ソフトウェア開発をより身近なものにする一方で、アプリをより速く、より簡単に、SQLインジェクションやパス・トラバーサル攻撃、悪意のある人物に狙われやすい秘密といった脆弱性や攻撃にさらすことにもなる。バイブコーディング・プラットフォームの中には、脆弱性に先手を打つ努力をしているものもありますが(v0はデフォルトでLLMコードに懐疑的です)、それでもバイブコーディングにはセキュリティ・ギャップの非常に現実的なリスクがあり、「バイブコーディング=Vulnerability-as-a-Service(サービスとしての脆弱性)」という皮肉な観察につながります。
下の例を見てほしい:

残念なことに、上記の不幸な友人がアプリをシャットダウンしてやり直さなければならなくなった明らかな理由は一つもない。彼のAPIキーが流出し、ハッカーが彼になりすまし、データ、機能、リソースにアクセスしたり、変更したりできたことは明らかだ。
アプリケーションへの秘密のハードコーディング、知らず知らずのうちにサーバーにアップロードされた環境変数ファイル、パストラバーサル脆弱性(アトラシアンでも起こった)の犠牲者などだ。追加のセキュリティチェックやプロセスがなければ、ハッカーやボットが彼のAPIキーにアクセスするのは簡単だっただろう。
一般的なセキュリティの脆弱性とリスク
あなたとChatGPTだけであろうと、Lovableのような専用ツールでバイブコーディングしていようと、このような一般的なタイプのサイバー攻撃には脆弱です。
クロスサイト・スクリプティング (XSS)
クロスサイト・スクリプティング(XSS)攻撃は、Web アプリケーションの脆弱性を悪用するもので、ユーザから提供された入力が、表示または処理される前に適切に検証またはサニタイズされません。ハッカーは、ユーザー入力を介して悪意のあるコードを「注入」することができ、注入されたスクリプトが実行されると、機密情報にアクセスしたり、被害者(この場合はユーザーの一人)の代わりに不正なアクションを実行したりすることができます。XSS攻撃は、(このセルフリツイートツイートのように)無害な楽しみの場合もありますが、ハッカーにデータを暴露されたり、アカウントを乗っ取られたりする危険性があります。
SQLインジェクション攻撃
XSS と同様に、SQL インジェクション(SQLi)攻撃は、多くの場合、脆弱なユーザ入力フィールドを経由して、アプリケーションに悪意 のあるコードを注入します。SQLは多くのアプリケーションが基礎となるデータベースへのクエリに使用する言語であるため、このタイプの攻撃を受けると、ハッカーはデータベースを閲覧または変更し、機密データにアクセスしたり、レコードを削除したりすることさえ可能になります。2017年のEquifaxのデータ漏洩はSQLインジェクション攻撃の結果であったが、Equifax自体は狙われていなかった。
パス・トラバーサル攻撃
攻撃者はファイル・パスの入力(典型的には URL やファイル・パラメータ)を操作して、アプリケーションを騙して非公開 のファイルやディレクトリを返させ、アクセス制御をバイパスして機密データを含むファイルへの読み書きを可能にします。この種の攻撃は、安全でないユーザー入力によっても可能になります。2010 年、研究者はアトラシアンの Confluence アプリケーションにパストラバーサル脆弱性を発見し、Confluence を実行しているユーザのパーミッションに基づいて、攻撃者が Confluence を実行しているサーバ上の任意のファイルを取得できるようにしました。
機密漏洩
パスワード、暗号化キー、APIトークン、デジタル証明書のような秘密は、悪質業者にあなたの王国への鍵を与えてしまいます。これらの機密データは、ハッカーがあなたになりすまし、データにアクセスし、コードを変更することを可能にします。GitGuardianのState of Secrets Sprawlレポートによると、2024年にはなんと2300万もの秘密が公開ソースコード・リポジトリで発見された(前年比25%増)。シークレットは、誤ってアプリケーションにハードコーディングしてしまったり、2025年3月に発生したtj-actions/changed-filesの侵害のような脆弱性によって公開されてしまう可能性があります。攻撃者はtj-actions/changed-files GitHub Actionのコードを修正し、侵害されたアクションがGitHub ActionsのビルドログにCI/CDシークレットを出力するようにしました。
サプライチェーン攻撃
アプリケーションのコードの85-95%は、オープンソースのライブラリやプロジェクトによって動いている可能性があります。サプライチェーン攻撃は、ある特定のタイプの脆弱性を悪用したり、特定のアプリケーションをターゲットにしたりするのではなく、多くの企業が依存している基本的なオープンソースプロジェクトを狙います。上記のEquifaxのデータ流出は、サプライチェーン攻撃の結果であり、すでに緩和されていました。これは、依存関係を監視し、セキュリティパッチを迅速に適用することの重要性を示しています。
Vibeコーディングは、コンセプトの探求や実証の構築には素晴らしいツールだが、何かを実行可能な製品やビジネスにすることに興味を持った瞬間、構築したものを守るためにセキュリティチェックやベストプラクティスを設定したくなるだろう。
AIにもっと安全なコードを書くように頼むことはできないのか?
これは妥当な質問だ。AIがデフォルトでセキュアなコードを書かないことは知っているが、非常に手っ取り早く汚い改善策は、セキュアにするよう明示的に求めることだ(プロンプトに文字通り「セキュアにする」という言葉を加えるように)。驚くことに、これは実際に脆弱性の少ないコードになる。
例えば、ハードコードされた秘密の発見、データが一般にアクセス可能でないことの検証、脆弱な依存関係のプロジェクト・スキャン、入力バリデーションが不十分なユーザ入力フィールド(フォームなど)の特定などです。これらの努力はすべて、あなたのアプリケーションのセキュリティを改善します。
しかし、AIが生成したコードに潜在的な幻覚や脆弱性、その他のセキュリティ・ギャップがないかを事実確認するポイントは、人間の監視なしにAIが勝手に修正するのはリスクが高すぎるということだ。AIを従来のスキャン手法と統合し、強化することは可能だが、置き換えることはできない(例えば、Aikido AIを使ってセキュリティ警告を自動選別し、修正を提案している)。
最強のソフトウェア・エンジニアはまた、自分が何かを知らないことを認めることに最も抵抗がない人たちでもある。AIに自らを監視させることに過度に依存すると、不確実性を認める代わりに、何か間違っていることについて確信に満ちた主張をしてしまうことが珍しくないという問題がある。これが、アプリケーションの安全性を確保するためにAIだけに頼ることを推奨しない理由だ。
良いニュースは、バイブ・コーディングが流行するずっと以前から、多くの企業やオープン・ソース・プロジェクトが、このようなセキュリティ問題に取り組むことに専念してきたことだ。新しい開発者が学ぶ最大の教訓の1つは、巨人の肩の上に立つことです。あなたのアプリケーションには、センシティブでミッション・クリティカルなコンポーネント(認証、暗号化、あるいはユーザーにUIにファイルをアップロードさせる方法など)がたくさんあるでしょう:
- 製品の差別化につながらない
- セキュリティリスクをもたらす可能性が高い
そのような場合は、純粋にそのような問題の解決に焦点を当てたプロバイダーを利用する方がはるかに良い。LLMは、ベストプラクティスや最も効率的で安全な方法での問題解決について特別な訓練を受けているわけではない。多くの場合、最もエレガントなソリューションは、独自に構築するよりも既存のサービスを利用することだ(たとえAIに重労働を任せるとしても)。
何から始めればいいのかわからず、圧倒されてしまいがちです。私たちは、あなたがより安全なビルドを開始するのに役立つチェックリストをまとめました。
レベル0
これらは、あなたができるだけ早く導入したいテーブルステークスのセキュリティ対策です。一旦これらの対策が確立され、プロセスの一部となれば、雰囲気を壊すことなく自由に構築することができる。
Gitのベストプラクティスを導入する
バイブ・コーディングにありがちな落とし穴のひとつは、新しい機能を追加したり問題を修正しようとしたりするときに、以前持っていたものをAIが生成した新しいコードに置き換える方が直感的だということだ。結局、AIが生成するものは何も役に立たず、以前よりもさらに悪い状態になってしまうという壁にぶつかるかもしれない。

バージョン管理はそのためにある
Git のようなバージョン管理は、開発者がお互いの作業を上書きすることなくプロジェクトで共同作業するための方法として登場しました。しかし、たとえあなたが一人でビルドしているとしても、Gitはあなたの進捗をバックアップする手段として役立ちます。これは、バグを切り分けたり、何か問題が起きたときに変更を元に戻したりするのに役立ちます。ここでは、より安全にビルドするための3つの重要なGitプラクティスを紹介します:
機密ファイル用の.gitignoreファイルを作成する
.gitignore ファイルは、Git に何を無視するか(つまり、リポジトリにコミットしないか)を指示するプレーンテキストファイルです。一般的には、ログのようなコンピュータが生成したファイルを Git に無視させたいでしょう。リポジトリが散らかったり、アプリケーションの情報が含まれていてそれを悪用されたりする可能性があるからです。.envファイルも無視すべきです。ハッカーがあなたになりすましてシステムにアクセスするための機密性の高い環境変数(APIキーやパスワードなど)が含まれているからです。
明確なコミット履歴の維持
変更を可能な限り自己完結させておくことで、バグや脆弱性がいつ発生したかを特定しやすくなり、他の作業をやり直すことなく簡単に元に戻すことができます。さらに一歩進んで、署名付きコミットを設定することで、正しい開発者があなたのリポジトリにコードをコミットしていることを確認できます(たとえそれがあなただけだとしても!)。
機能開発ブランチ、ステージングブランチ、プロダクションブランチの分離
Git でのブランチは、コードの作業、プレビュー、リリースのための自己完結した空間を作るのに役立ちます。新しい機能を積極的に別のブランチで開発することで、未完成でバグの多い、あるいは安全でないコードが誤って本番のアプリケーションにコミットされるのを防ぐことができます。新機能の開発とテストが完了したら、ステージングブランチはもうひとつのセキュリティ・品質ゲートとして機能します。完全にテストされ安定した機能だけが、本番環境 (通常は main) ブランチにマージされます。
ホスティングされたGitリポジトリGitHub GitLab
秘密はコードから切り離す

パスワード、暗号化キー、APIトークン、デジタル証明書などのシークレットは、コードベースに直接コミットしないように、コードとは別に扱う必要があります。Cursor IDEからでも、Aikidoコードに秘密がないかチェックできます。
DDoS攻撃からアプリを守る
分散型サービス拒否攻撃(DDoS)は、インターネットトラフィックの急増でターゲットまたはその周辺のインフラストラクチャを圧倒することにより、ターゲットとしたサーバー、サービス、またはネットワークの正常なトラフィックを妨害しようとします。これらの攻撃は壊滅的な結果をもたらす可能性があり、基本的なDDoS防御をCloudFlareや CloudFrontのようなコンテンツデリバリーネットワーク(CDN)と統合することで、驚くほど簡単に身を守ることができます。ドメインホスティングプロバイダーの中には、CDNを内蔵サービスとして提供しているところもあります。
認証をひとりでやらない
認証(ログインフローなど)は、アプリケーションの機密性の高いコンポーネントであるため、専門家に任せたいものです。専用のツールを使ってパスワードポリシーを実施し、シングルサインオンや多要素認証をアプリに簡単に提供することで、規模を拡大してもユーザーアカウントと評判を守ることができます。
自分自身で暗号を作らない
同じ意味で、暗号は専門技術なので、常に確立されたメカニズム、ライブラリ、ツールに頼ってください。独自の実装を構築したり、十分に理解していないフラグやオプションを使用するのはやめよう、
それは大きなリスクにさらされることになる。NaCLのようなライブラリーは、選択肢を少なくし、良い選択を制限する。
レベル1
CI/CDパイプラインをセットアップしてコードを監視する
CI/CDパイプラインにテストを実装することは、アプリケーションコードの組み立てラインに品質チェックポイントを追加するようなものです。静的コード解析ツールを統合して、静的アプリケーションセキュリティテスト(Static Application Security Testing: SAST)を実施することができます。また、ダイナミック・アプリケーション・セキュリティ・テスト(DAST:Dynamic Application Security Testing、サーフェスモニタリングと呼ばれることもあります)用のツールを統合して、攻撃をシミュレートし、ウェブアプリケーションのフロントエンドの脆弱性を特定することもできます(オープンポートや無制限のインバウンドトラフィックを探すなど)。
オープンソースDASTZAP
オープンソースSASTオープングレップ
依存関係を監視する
あなたが意識しているかどうかに関わらず、あなたのアプリケーションを動かすコードのほとんどは、AIモデルが学習するオープンソースプロジェクトやサードパーティライブラリから引き出されている可能性が高い。これらはあなたの依存関係であり、時にはそれらにも独自の依存関係があり、これらすべてがあなたのソフトウェアのサプライチェーンを構成している。これらのライブラリのどれかに1つでも欠陥があれば、アプリケーション全体が危険にさらされる可能性があります。しかし、適切なツールを使って依存関係に既知の脆弱性がないか監視することで、リスクを減らすことができます。
おすすめツールトリビー
依存関係にマルウェアがないかチェックする
同様に、あなたのサプライチェーンには、マルウェアを含む悪意のあるパッケージが含まれている可能性があります。攻撃者は通常、マルウェアをあなたのコードに侵入させることに成功した後、素早く行動するため、これらは非常に危険である。そのため、あなたも迅速に対応する必要がある。CVE(Common Vulnerabilities and Exposures)データベースは遅すぎて、この種の攻撃からあなたを守ることはできない。
ロックファイルを使用してサプライチェーンを保護
lockfilesを使用しない場合、アプリケーションをビルドするたびに、すべてのオープンソース・パッケージの最新バージョンを取り込むことになります。Lockfiles は、オープンソースの依存パッケージの同じバージョンを取り込むことで、再現可能なビルドを可能にします。これにより、依存関係に何らかの変更があった場合でもアプリケーションの安定性が保たれるだけでなく、依存関係の最新バージョンが侵害された場合のサプライチェーン攻撃からアプリケーションを保護することもできます。最近の例としては、2025年3月のtj-actions/changed-filesの脆弱性があります。攻撃者はtj-actions/changed-filesのGitHubアクションのコードを変更し、侵害されたアクションがGitHubアクションのビルドログにCI/CDの秘密を出力するようにしました。
厳格なCSPヘッダーでクロスサイト・スクリプティング攻撃を防ぐ
CSP ヘッダーは、どの動的リソースのロードを許可するかを制御する追加のセキュリティ・レイヤーを提供することで、一般的な XSS 攻撃から保護することができます。これにより、攻撃者がウェブページにスクリプトを注入するのを防ぐことができます。
ウェブアプリケーションファイアウォールを使用する
ウェブアプリケーションファイアウォール(WAF)またはランタイムアプリケーションセルフプロテクション(RASP)を使用して、未知の SQL インジェクションや XSS の脅威など、未知のゼロデイ脅威からウェブサーバーを保護します。このツールは、疑わしい動作や悪意のある動作(インジェクションのペイロードなど)をするユーザーリクエストをスキャンして防止し、攻撃に対する最後の防御ラインとして機能します。
素晴らしいツールAWS WAFAikido Zen
レベル2
上記のセキュリティ対策が整ったところで、セキュリティ態勢をレベルアップさせる時が来た。
コンテナのベストプラクティスを導入する
コンテナはソフトウェアをパッケージ化し、あるコンピューティング環境から別の環境へ移動したときに確実に実行できるようにします。コンテナは、ライブラリ、フレームワーク、設定ファイルなど、アプリケーションに必要なすべての依存関係(サプライチェーンのすべて)を1つのパッケージにバンドルします。これにより、デプロイされる環境にかかわらず、アプリケーションが一貫して実行されることが保証されます。
デプロイにコンテナを使用する場合、アプリケーションの堅牢化に役立つベストプラクティスがいくつかある。
Dockerベースイメージを常に更新する
ベース・コンテナ・イメージ(コンテナが構成される設計図)の脆弱性は、アプリケーションを危険にさらします。ベース・イメージのすべてのセキュリティ・アップデートを定期的にダウンロードしてください。サーバーの場合は、HerokuやAWS BeanstalkのようなPaaSプロバイダーに任せることができます。
DockerのセキュリティをスキャンするSyft Grype Trivy
制限された権限でDockerコンテナを実行する
特権を制限することで、成功した攻撃者がホストを乗っ取ったり、他のサービスにバウンスしたりすることが難しくなる。Unixシステムではroot、WindowsシステムではAdministratorやSystemなど、特権ユーザー・ロールでコンテナを実行しないようにする。
秘密を守る
秘密をコードから分離することは、素晴らしいスタートだ。コンテナを使用している場合は、シークレットファイルやその他の機密データが適切に保護されていることも確認したい。これには、シークレット管理ツールの使用(多くのクラウドプロバイダーが独自のものを提供している)、Kubernetesを使用している場合はKubernetesシークレットの使用、シークレットの定期的なローテーション、シークレットの有効期限の設定などが含まれる。
秘密管理ツールHashiCorp Vault AWSシークレットマネージャー Googleクラウドシークレットマネージャー
続きを読むコンテナにおける秘密の安全な管理:ベストプラクティスと戦略
パッケージの使用期限(EOL)を確認する
パッケージが古くなりサポートが終了すると、悪用される危険性が高まります。間もなくサポートが終了するパッケージは、必ずアップグレードするようにしましょう。
また、Aikidoコンテナスキャン機能を使えば、数秒でセットアップが完了する。
クラウドアカウントのベストプラクティスを導入する
開発用、ステージング用、本番用のクラウドアカウントを分ける
開発用、ステージング用、本番用の Git ブランチを分けておきたいのと同じように、クラウドアカウントも同じです。クラウドアカウントの中に仮想ネットワークを作ってステージングと本番を分けておくこともできますが、新しい開発者のためにユーザーのアクセス権を管理し続けることになり、成長するにつれて面倒なことになりかねません。開発インフラ、ステージング・インフラ、本番インフラを完全に別のクラウド・アカウントで管理することをお勧めする。どのクラウドプロバイダーも統合課金を提供しているので、頭痛の種が一つ減る。
クラウド姿勢管理ツールの使用
クラウド・プロバイダーは非常に多くの機能を提供しているため、リスクにさらされるような何かを見逃したり、設定を誤ったりしがちだ。クラウド・セキュリティ・ポスチャ管理(CSPM)ツールを使用して、クラウドに異常がないかスキャンしましょう。
CSPM ツールCloudsploit AWS Inspector
クラウド予算アラートの有効化
あなたのクラウドアカウントがハッキングされた場合、誰かがあなたのアカウントでビットコインをマイニングしていることを検知する確実な方法の一つは、支出を監視するために予算アラートを設定することです。クラウドプロバイダーは、このためのビルトインアラートを提供するはずである。また、 Aikidoクラウドスキャンをセットアップして、予算の懸念やリスクのある誤った設定をチェックすることもできる。
最も一般的なエクスプロイトについてLLMをチェックする
LLMを使って構築するだけでなく、LLMを一般向けの製品に統合することもあるでしょう。チャットボットがユーザーにサポートを提供したり、AIアシスタントがユーザーの搭乗をサポートしたりするかもしれない。顧客が何らかの形でLLMとやり取りする場合、顧客をセキュリティリスクにさらすことがないよう、最も一般的なエクスプロイトについてテストすることをお勧めします。
最も一般的なエクスプロイトをチェックLLMのためのOWASPトップ10
その先
安全な開発ライフサイクルの導入
最新のセキュリティ対策の大部分は、開発ライフサイクルにセキュリティ対策を早期に導入することである。これによって、プロジェクトの各段階で優れた実践を習慣づけることができ、本当の脅威になる前に問題を早期に発見することができる。つまり、このようなセキュリティチェックリストを遵守し、典型的なセキュリティ上の欠陥に精通し、コードレビュー中にその欠陥に注意し、プルリクエストにもセキュリティチェックを実施することです。
続きを読むOWASPトップテン
もっと読むシステム開発ライフサイクルに関するウィキペディアの記事
誰でもサイバー攻撃の犠牲になる可能性があります。セキュリティ専門部署を持つ多国籍企業でさえ、依然として侵害の危険にさらされています。バイブ・コードがデフォルトでセキュアなわけではありませんが、最初からセキュリティのベスト・プラクティスを採用することで、バイブに完全に委ねることができます。何を作るにしても、努力する価値はある。
さらに読む