Microsoftの研究者らが、バイブコーディングで作られた公開中のWebアプリを調査したところ、約9割で脆弱性が確認されたと報告した。ただし、この割合は、バイブコーディングで作られたオープンソースソフトウェアと、OWASPに寄せられた脆弱性情報を比較した調査結果に基づくもので、両者の開発環境や確認方法は異なる。
事案の詳細
調査を行ったのはMicrosoftの研究者らで、対象はバイブコーディングで作られた公開中のWebアプリケーション、具体的にはオープンソースソフトウェアだった。調査では、対象の約9割に脆弱性が確認されたという。
脆弱性の確認には、AIエージェントによる監査と人手による確認が用いられた。一方、比較対象となったOWASPの脆弱性情報は、企業が開発したソフトウェアのテスト結果などを基にした情報であり、対象や検証手段が異なる。
このため、調査結果はバイブコーディングで作られたソフトウェアに脆弱性が多い可能性を示すものの、一般のソフトウェアと比べて脆弱性が「20倍」多いといった数値を、そのまま開発手法の差によるものと解釈することには注意が必要だ。個別のアプリ名、脆弱性の種類、攻撃手法の詳細は、現時点で確認できない。
公開中のWebアプリはインターネット経由で第三者からアクセスされ得るため、脆弱性が残っている場合には不正アクセスや情報漏えいなどにつながる可能性がある。ただし、今回の報告から、実際に被害が発生したかどうかは明らかになっていない。
影響と背景
公開中のWebアプリに脆弱性が含まれている場合、外部からの攻撃や情報漏えいにつながり得るため、開発者や運用者にとって無視できないリスクとなる。今回の調査は、バイブコーディングで作られたソフトウェアについて、公開前後のセキュリティ検証が必要であることを示す材料になる。
一方、調査対象となったソフトウェアと比較対象のOWASP情報では、開発主体、ソフトウェアの種類、脆弱性の収集方法、検証手段が異なる。したがって、約9割という割合を、すべてのバイブコーディング製アプリに直接当てはめることはできない。調査対象の規模や個別の脆弱性の内訳など、詳細は現時点で不明だ。
対策・今後の展望
- 公開前後の点検を徹底する：公開中のWebアプリは常に外部から見られる前提に立ち、AIエージェントによる監査だけでなく、人手によるコードレビューや脆弱性診断も組み合わせる。
- 修正と再確認を短いサイクルで回す：脆弱性が見つかった場合は修正し、修正後に再度確認する流れを定着させる。認証やアクセス制御、入力値の検証など、基本的な安全対策も確認する。
- 責任範囲を明確にする：誰が開発し、誰が公開可否を判断し、誰が保守するのかを事前に決め、公開後の更新や脆弱性対応を継続する。
CSRIからの現場アドバイス
【現場で何が起きているか】CSRIが支援する中小企業の診断現場では、公開中のWeb画面に対する基本的な点検が抜けたまま運用されている例が少なくありません。とくに「公開した後は触らない」状態になり、設定や更新が追随しないケースが目立ちます。
【平易な解説】例えるなら、急いで作ったお店の入口に鍵の掛け忘れが残っているようなものです。つまり、見た目は動いていても、外から入られて困る場所が開いたままになっている可能性がある、ということです。
【今週中にできること】まず、社内で公開中のWebアプリがどれかを一覧にして担当者を決めてください。次に、公開中の画面や管理機能が想定外に誰でも触れないかを確認します。最後に、修正や点検を「公開後も続ける」運用ルールを共有します。