脆弱性管理
【セミナーレポート】AI攻撃時代のセキュリティUPDATE 直近の攻撃動向から読み解く「攻め方」と「守り方」
2026年11月5日（木）に、オンラインセミナー「AI攻撃時代のセキュリティUPDATE 直近の攻撃動向から読み解く『攻め方』と『守り方』」を開催しました。登壇したのは、Cloudbase株式会社 VP of Engineering／セキュリティ事業責任者の成瀬真です。
10月21日に公表されたPHP2Shellを例に、攻撃者がAIを使うようになって変わったことと変わらないことを整理し、自社環境の脆弱性を確かめる方法をCloudbaseの画面で実演しました。
（この記事は、セミナー内容を再構成しております。）
日時：2026年11月5日（木）11:00〜12:00
形式：オンライン（Zoomウェビナー）
登壇：成瀬真（Cloudbase株式会社 VP of Engineering／セキュリティ事業責任者）
PHP2Shellは、いつ見つかり、いつ悪用が始まったか
最初に、10月21日に公表されたPHP2Shellについてお話しします。PHP2Shellは、プログラミング言語PHPの本体にある重大な脆弱性です。PHPはウェブサイトで広く使われていますので、自社で書いたコードに問題がなくても、使っているPHPのバージョンによっては影響を受けます。
PHP2Shellを見つけたのは、セキュリティ企業Califの研究者です。8月1日に、OpenAIの取り組み「Patch the Planet」の一環で、AIを使って発見しました。修正版とCVEが公開されたのは10月21日の夜です。ただ、それより前の10月17日には悪用の試行が観測されていました。
PHP2Shellは、どの環境でも簡単に攻撃コードを作れる種類の脆弱性ではありません。それでも本日取り上げたのは、公表より前に悪用が始まった事例だからです。
2021年12月のLog4Shellのあとも、2025年12月にReact2Shell（React）、2026年7月にWP2Shell（WordPress）と、多くのシステムに部品として組み込まれたソフトウェアで、重大な脆弱性の公表が続いています。脆弱性を探す研究でも生成AIの活用が進んでいますので、同じような脆弱性の発見は今後も続くと私たちは見ています。
攻撃者がAIを使うようになって起きた変化
私たちCloudbaseは、攻撃側が生成AIをどのように使う可能性があるか研究をしています。その研究を通じて、守る側がこれまで前提にしてきた2つのことが、AIを使った攻撃では当てはまらない場合があると分かってきました。
1つ目は、攻撃コードを作るには専門知識が要るので、公表から悪用が広がるまでに修正する時間がある、という前提です。脆弱性の公表から攻撃コードが出て、KEV（米CISAが公開している、悪用が確認された脆弱性の一覧）に登録されるまでの期間は、年単位から日単位・時間単位に縮んでいます。PHP2Shellを見つけたCalifも、最初の発見には特別な仕組みも、一般に公開されていないモデルも使っていないと記事に書いています。
2つ目は、同じ手口が続くので、攻撃のパターンを覚えておけば検出できる、という前提です。攻撃者は、そのつど生成AIで新しいツールを作れます。そのため、過去のパターンを登録して待ち受ける方法では、検出しにくくなっています。
攻撃者が狙う「入口」
攻撃の量と速さは変わりましたが、狙われる入口はこれまでと同じだと私たちは考えています。生成AIを使う攻撃者が狙うのも、インターネットに公開された資産、過剰な権限が付いたID（IAMユーザーやロールなど）、悪用が確認された脆弱性の大きく3つです。
ここで、わたしたちが社内の研究で使っている、外部から自律的に侵入を試みるツールの実験について紹介します。生成AIには、「システムに侵入して情報を抜き出してください」という指示と、私たちが開発したエージェントの実行環境を与えました。約1時間の試行で、生成AIは次の順に進み、指示どおり情報を抜き出しました。
ウェブアプリケーションの認証・認可の不備を突く
アプリケーションの脆弱性を突いて、内部の別のシステムへ侵入を広げる
侵入先で、過剰な権限を持つIDを見つけて悪用する
その権限でアクセスできる情報を盗み出す
この実験でも、生成AIはまだ知られていない脆弱性を発見したわけではありません。既知の脆弱性をはじめ、先の3つの入口のうち対策が足りていない箇所を、速く、大量に狙っていました。3つの入口の対策ができている環境では、現在の最先端の生成AIでも、自律的にシステムを侵害して情報を持ち出すのは難しいと私は考えています。ただ、これは現時点の話で、来年には状況が変わっているかもしれません。
AIの侵入ツール、守る側も使うべき？
この侵入ツールを、私たちはお客様に提供する予定はありません。外部から情報なしで試す方法では、攻撃者のAIと同じ条件で脆弱性を探すことになり、守る側が持っている自社環境の情報が生かされないからです。このツールで見つかる脆弱性は、すでに攻撃者にも見つかっていると考えた方がよいと思います。
守る側は、攻撃者と同じ高性能なモデルを使えることに加えて、自社環境の情報（コンテキスト）を持っています。構成情報、リスク情報、ソフトウェアの情報、対応履歴、それから担当者が知っている事情です。こうした自社の情報を使って守ることを、私たちは重視しています。
重大な脆弱性の公表直後から、影響範囲を調べる方法
PHPに重大な脆弱性が公表されたら、グループ企業や委託先を含めて影響範囲を特定し、バージョンを確かめ、修正版を適用するか緩和策をとるかを決めます。影響範囲を特定するところで時間がかかる企業には、次のような事情があります。
開発を外部に委託していて、構成を把握しきれていない
システムやクラウドのアカウントが部署ごとに分かれていて、全体をつかみにくい
ソフトウェアの台帳をExcelで管理しているが、更新されず実態と合っていない
公表のたびに、各部署や委託先へメールやアンケートで1つずつ確認している
影響を受ける環境を、CVE番号とソフトウェア名の両方で探す
CVE番号での検索に加えて、ソフトウェア名とバージョンで探す方法もあります。CVE番号が割り当てられる前の、「特定のソフトウェアの特定のバージョンに脆弱性があるらしい」という段階の情報から、自社のどこで使っているかを調べ始められるからです。
AWS・Microsoft Azure・Google Cloudとオンプレミスのネットワーク機器をつないだデモ環境を用いて解説します。CVE番号で検索すると、該当するEC2インスタンスとオンプレミスのネットワーク機器が一覧で出て、それぞれのソフトウェアやOSのバージョンも確認できます。ネットワーク機器では、PHPのようなソフトウェアではなく、OSのバージョンに脆弱性の情報が紐づく場合もあります。
続いて、ソフトウェアの一覧（SBOM）を「php-cgi」で検索すると、先ほどCVE番号で見つかったのと同じEC2インスタンスが見つかります。Java・Python・PHP・Node.jsなどのソフトウェアを、グループ企業や委託先の環境も含めて横断的に検索できます。次にRubyやJavaで脆弱性が公開されたときも、同じ手順で調べられます。
サポートが終わったOSやソフトウェアのバージョンを、先に洗い出す
サポートが終わったバージョンを先に洗い出しておくことも備えになります。PHPの開発元は、サポートが終わったバージョンには、原則として公式の修正版を出していません。例外的に修正版が出るケースもありますが、通常とは違う更新の手順になります。
デモ環境では、先ほどのEC2インスタンスはOSのサポートがすでに終わっていて、php-fpmもあと56日でサポートが終わる状態でした。次に脆弱性が出たときにすぐ修正版を適用できるよう、古いものから更新を進めておきたいところです。
PHP2Shellの公表後に、私たちが行った対応
Cloudbaseを導入しているお客様に向けて、私たちは次の対応を行いました。
注意喚起を送り、Cloudbaseでの検索方法をご案内しました
KEVの追加を待たずに、悪用が報告されている脆弱性として登録しました（米CISAがKEVに追加したのは10月27日）
お問い合わせのあった企業には、該当するリソースの一覧を共有しました
パッケージ管理を使わずにソースからビルドしたPHPも、検出の対象に加えました
脆弱性の情報（アドバイザリ）が出る前の段階から検出できるよう、仕組みを改めました
重大な脆弱性が公表されたあとに確認しておきたい５点
Cloudbaseをお使いかどうかにかかわらず、次に重大な脆弱性が公表されたときに備えて、以下の5点を確認しておくことをおすすめします。
グループ企業や委託先を含めて、影響を受けるソフトウェアを名前とバージョンで探せるか
パッケージ管理を使わずに入れたソフトウェアも、探す対象に入っているか
各環境のバージョンと、修正版を適用したかどうかを一覧で確認できるか
サポートが終わったバージョンが残っていないか
すぐに修正版を適用できない環境に対して、緩和策を決めてあるか
検出した脆弱性から、実際に攻撃が成り立つか
ここからは、守る側も生成AIを使って検証する方法を2つご紹介します。
守りの検証（AIバリデーション）：検出した脆弱性で、実際に攻撃が成り立つかを確かめる
攻めの検証（AIペネトレーションテスト）：攻撃者の目線で目標を決め、重要な資産までたどり着けるかを確かめる
AIバリデーションでは、仮想マシンのスナップショットを私たちのクラウド環境で復元し、その複製に対してAIがコマンドを実行して、悪用の条件がそろっているかを確かめます。Cloudbaseはもともと、脆弱性を検出する過程で、スナップショットから復元した複製環境を使っています。検証にも同じ仕組みを使うので、お客様の本番環境や稼働中の仮想マシンには触れずに検証できます。
脆弱性管理製品の検出は、そのソフトウェアがファイルとしてインスタンスやコンテナの中にあるかどうかまでしか見ていません。攻撃が成り立つかは、アプリケーションのコードが悪用されうる書き方になっているか、サービスが起動しているかでも変わります。たとえば多くのLinux環境では、カーネルを更新したあとも古いカーネルのファイルを残す設定になっています。そのため、脆弱なバージョンのファイルはあっても、実際には使われていないケースが多くあります。
新たに公表された、圧縮形式Brotliのライブラリの脆弱性を例にします。AIがコマンドを実行して確かめるのは、次の3点です。
脆弱なバージョンの共有ライブラリが実際にあるか
ネットワーク通信を受け付けるプログラム（ランタイム）が、そのライブラリを動的にリンクしているか
そのプログラム上のアプリが、外部から受け取ったデータをBrotli形式で展開する処理を持っているか
Brotliは多くのソフトウェアに組み込まれているので、この脆弱性は多くの環境で検出され、対応に追われた方も多いと思います。一方で、Brotliの展開が実際には使われていない環境の方が多いと私は見ています。デモ環境では、この脆弱性が検出された18台のうち、条件がそろっていたのは3台でした。
条件がそろっていないからこの脆弱性には対応しなくてよい、とまでAIが自律的に判断するのは難しいと思います。それでも、条件の成立を自動で確かめておけば判断の材料になります。条件がそろっている環境から優先して対応する、3つの条件のうち2つが欠けている環境はいったんリスクを受け入れる、といった判断です。脆弱性の報告件数が大きく増えるなかで、この確認は自動で行う必要があります。
攻撃者は、重要な資産までたどり着けるか
AIペネトレーションテストを、私たちは「コンテキスト・ドリブン・ペネトレーションテスト」として提供しています。内部の情報を広く集めるホワイトボックス型で、複数のアカウントやクラウドをまたいだ範囲を継続的に検査します。守りたい資産と検査の確認事項を選ぶと、AIが経路を探して攻撃が成り立つかを確かめます。必要に応じて、私たちのセキュリティエンジニアが結果を確認して報告します。
開発中の画面で、決済を行うAPIに、WAFを通らずに到達する経路を見つける例をお見せします（画面は今後変わる可能性があります）。生成AIは次の情報を集めて静的に解析し、WAFを迂回する経路でAPIに到達でき、APIの脆弱性を突かれるおそれがあると判断しました。
AWS Configの設定情報に、インターネットから到達できる規則がある
VPCフローログに、実際の通信の履歴がある
ASM（Attack Surface Management。外部から見える資産を調べる製品）で、外部からの応答がある
外部のファイアウォールに、その通信を止める規則がない
検査では、何を目的に解析するかが大事になります。1つは、データベースやストレージなど、守りたい資産へのあらゆる経路を探す方法です。もう1つは、設計の意図からずれた経路を探す方法です。本番環境のアプリケーションで脆弱性を突けなかったとしても、問題がないとは言えません。そのため、開発環境から本番環境に到達してしまう経路や、CI/CDパイプラインから侵入して重要な資産に到達する経路も調べます。
最終的には、実際にコマンドを実行して到達できるかを確かめる動的な検証も要ります。ただ、コンテキストを集めて静的に解析しないまま、初めから手当たり次第に動的な検査をするのは適切ではないと考えています。特にパブリッククラウドの環境では、攻撃を実行しなくても、内部の攻撃経路や到達経路を静的に解析できます。コンテキストがそろうほど、実際にリクエストを送る必要は減っていきます。
Cloudbaseで管理できる環境と機能
最後に、Cloudbaseについてご紹介します。
Cloudbaseは、クラウドとオンプレミスの資産と設定、資産を構成するソフトウェアの一覧をまとめて見える状態にし、設定ミスと脆弱性を管理できる国産のセキュリティプラットフォームです。対象は、AWS・Microsoft Azure・Google Cloud・Oracle Cloudと、オンプレミスのサーバー・ネットワーク機器です。PC・スマートフォンなどの端末は、現在は対象外です。資産管理、設定ミスの検出、脆弱性管理に加えて、AIによるペネトレーションテストを行えるプラットフォームを構築しています。
主に大企業に導入いただいています。製造業から導入が進み、現在は金融、小売、エンターテインメントなど幅広い業種の企業にご利用いただいています。
セミナー参加者から出た質疑応答（抜粋）
Q 年1回の外部ペネトレーションテストを実施しています。AIペネトレーションテストはその代わりになりますか。それとも併用する想定ですか。
成瀬 私たちのAIペネトレーションテストには、静的な解析を自動で行う形に加えて、セキュリティエンジニアがついて、従来のペネトレーションテストと同じように実施する形もあります。対象の環境によっては、従来のテストの代わりになります。一方で、年に1回実施すれば、次の検査までの1年間は何もしなくてよい、という状況ではなくなってきています。年1回の人による検査に加えて、静的な解析を年間を通じて続ける方法をおすすめしています。
Q 開発を複数の委託先に任せていて、委託先が管理するAWSアカウントもあります。その環境も含めて、PHPのバージョンを一覧で把握できますか。
成瀬 できます。SIerに開発を任せ、そのSIerが管理するAWSアカウントがあるお客様の多くが、そのアカウントも同じCloudbaseにつないで管理しています。ユーザー企業がそのAWSアカウントに入る権限を持っていない場合でも、Cloudbaseの画面で脆弱性や設定ミスを確認できます。修正版の適用や是正の作業は、委託先に依頼していただくことになります。
Q ペネトレーションテストの実施環境を準備するのがボトルネックになっています。よい方法はありますか。
成瀬 静的に解析する段階では、本番環境であっても負荷をかけないので、実施環境を用意する必要はありません。過去の事例では、事前にコンテキストを集めてシナリオを作り、攻撃が成り立つかを試すデータ（ペイロード）を含むリクエストを、2時間で送り終える計画にしました。このときは深夜に2時間のメンテナンス時間をとっていただき、その間に確認を終えました。攻撃が成り立つかの最後の確認を、複製した環境で行ったお客様もいます。手法ごとに長所と短所がありますので、ご相談しながら決めています。
Q SIベンダーとして複数社の保守をしています。複数のAWSアカウントの情報を集めて管理できますか。
成瀬 できます。Cloudbaseには「プロジェクト」という単位があり、プロジェクトごとにクラウドアカウントを紐づけられます。1つのプロジェクトの中でも、すべてのプロジェクトを横断しても、脆弱性の管理や一覧の確認ができます。お客様の会社ごとに権限を分けて管理することもできます。
Q 脆弱性の収集にはAmazon Inspectorを使っています。Cloudbaseを使う利点は何ですか。
成瀬 脆弱性管理では、検出できるパッケージの数と、優先度の付け方の適切さが大事だと考えています。検出については、私たちの分析では、Amazon Inspectorより多くのパッケージの脆弱性を検出できています。加えてCloudbaseは、リソースの構成図を自動で作り、EC2インスタンスが最終的にインターネットに露出しているかを自動で判定します。露出の分析を含めた優先度付けや、AIバリデーションなど、検出したあとの対応を進めるための機能に利点があると考えています。脆弱性を検出しても直せない、という課題をお持ちのお客様が多いからです。
Q オンプレミスの機器からは、どんな情報を集められますか。
成瀬 オンプレミスでは、私たちが開発したセンサーエージェントをサーバーに入れていただきます。センサーエージェントを入れたサーバーでは、クラウドと同じように、ソフトウェアの一覧や脆弱性を管理できます。オンプレミスでは、どんな資産があるかを洗い出すこと自体が課題になっている場合も多いので、ディスカバリー機能で、センサーエージェントを入れたサーバーと同じネットワーク内にある仮想マシンやネットワーク機器も見つけます。ネットワーク機器にはSNMPで接続して認証し、OSのバージョンを特定します。そのOSに紐づく脆弱性の情報は、私たちが各社のアドバイザリから集めています。クラウドのインスタンス、オンプレミスのサーバー、ネットワーク機器を、同じ画面で同じように管理できます。オンプレミスのネットワーク機器の脆弱性から侵入され、クラウドまで被害が広がった事故も起きていますので、オンプレミスのサーバーやネットワーク機器も含めて脆弱性を管理することをおすすめしています。
Q ネットワーク機器やオンプレミスの機器を、台帳として書き出して管理したい場合はどうなりますか。
成瀬 資産には、AWSとほぼ同じ形式でタグを付けられます。所有するチームや管理部門のタグを付けてCloudbase上で台帳として管理し、必要なときに書き出して使っているお客様が多くいます。ネットワーク機器の一覧や、見つかったもののまだ接続していない資産の一覧も書き出せます。まだ接続していないサーバーの一覧を書き出して、接続を進める連絡に使っているケースもあります。
Q オンプレミスのネットワーク機器にもセンサーエージェントを入れるのですか。通信ポートの制限はありますか。
成瀬 ネットワーク機器に直接センサーエージェントは入れません。センサーエージェントを入れたサーバーから、SNMPで定期的に機器のOSを確認します。決まったポートを開けていただく必要はありません。ただ、センサーエージェントが集めた情報をCloudbaseに送るため、センサーエージェントを入れたサーバーには外向きの通信を許可していただく必要があります。外向きも内向きも閉じている環境では、中継用のサーバーを用意するか、ソフトウェアの一覧（SBOM）の情報を送るための通信ルールを追加していただくことになります。
【お知らせ】12月にもオンラインウェビナーを開催予定です
12月にもオンラインイベントを開催する予定です。詳細は決まりしだい、メールとこのサイトでご案内します。
Cloudbaseの機能や料金、お使いの環境に導入できるかのご相談は、お問い合わせからご連絡ください。
この記事で参照した資料
Calif「PHP2Shell: A tale of two PHP remote vulnerabilities」（2026年10月21日）
OpenAI「Patch the Planet：エージェントによる重大な脆弱性の発見と世界規模の対応連携」（2026年10月21日）
