はじめに：1週間で9つの機関が警鐘を鳴らした10月

2026年10月、日本のサイバーセキュリティ業界は異例の空気に包まれました。

10月7日の個人情報保護委員会を皮切りに、約1週間で9つの機関が、相次ぐ情報漏えいとサイバー攻撃に対して、それぞれの立場から警鐘を鳴らしました。

大量の個人情報を取り扱うオンラインサービスや業務システムが侵入され、本人確認書類の画像を含むデータまで窃取されるような事案が続きました。

そして息つく間もなく、10月21日にはPHPのセキュリティリリースの事前予告、22日には「PHP2Shell」と呼ばれる脆弱性（CVE-2026-109618、CVE-2026-109619）への対策を促す注意喚起が出されました。

この記事では、9機関の注意喚起を読み解きながら、いまなぜASM（Attack Surface Management）が必要なのかを解説します。そして、PHP騒動で多くの企業が直面した「自社のサプライチェーンのどこでPHPが動いているのか分からない」という問題に、どう合理的に答えを出すかを考えます。

9機関の注意喚起に共通する課題と3つの観点 

9つの文書を並べて読むと、言葉は違っても同じことを言っていると気づきます。

それは「自分たちが外に何をさらしているのかを、正確に把握できていない」という課題です。

この課題は、次の3つの観点に整理できます。 

• ① 侵入の起点は「インターネットに公開されているもの」

• ② 守るべき範囲は「自社の外」にまで広がっている

• ③ 攻撃者はAIで、速く、広く探している

1つずつ、解説します。

① 侵入の起点は「インターネットに公開されているもの」

国家サイバー統括室（以下、NCO）は「インターネットに公開されているシステムは特に攻撃の対象となりやすい」と明言し、利用していないシステムや機能の停止・削除、不要なポートやサービスの無効化を求めています。

IPAは公表事例の傾向から、外部公開しているアプリケーションやサービスの侵害、アカウントの侵害が起点となっている可能性を指摘し、まず自組織の外部公開アプリケーションがあるかどうかを確認するように呼びかけました。

JPCERT/CCは、BIツールや従業員向け管理システムなど「不特定多数の利用者からのアクセスを想定していないシステム」まで被害に遭っていると指摘しています。

「内部向けのつもり」「公開していないつもり」のシステムが、実際には外から見えている。
これが今回の一連の事案におけるリスクの本質です。

② 守るべき範囲は「自社の外」にまで広がっている

個人情報保護委員会は、海外拠点に設置された貸与品のVPN装置が台帳に載っておらず、存在自体が把握できなくなっていた事例を紹介しています。対策として示されたのは、海外拠点も含めたIT資産の洗い出しです。

NCOは「比較的防御が弱い委託先企業等を足掛かりとして侵入」する手口に触れ、再委託先を含む管理状況の把握を求めました。

経済産業省は「自社のみならず、サプライチェーン全体でセキュリティを管理する」という認識を、金融庁はサードパーティリスク管理を含む点検を求めています。

つまり、自社の情報システム部門が管理する台帳だけを見ていても、攻撃者の入口は防げない・防ぎにくいということを示唆しています。

③ 攻撃者はAIで、速く、広く探している

NICTは、公開されているAndroidアプリを解析して接続先サーバやAPIの仕様を割り出し、狙い撃ちする「A2B攻撃」を特定しました。そして、AIの活用によってアプリの解析や脆弱性の発見が効率化され、攻撃が多くのシステムに広がる可能性に警鐘を鳴らしています。

JPCERT/CCは、2026年10月23日の更新において、AIを用いたペネトレーションテスト基盤を悪用し、インターネットに公開されたWebアプリケーションを探索する攻撃試行を確認しています。

攻撃者はすでに、インターネット全体を「外からの目線」で網羅的に調べ上げています。守る側だけが、自社の姿を正確に把握できていないことが少なくありません。この非対称こそが、いま解消すべき課題です。

実際に、9機関の注意喚起から「外部公開資産の把握」や「委託先・グループを含む資産確認」に触れた箇所を抜き出すと、次のとおりです。「ASM」という言葉こそ使っていませんが、求めていることはASMの考え方と大きく重なります（引用は原文。各機関の出典URLを併記しています）。

9つの機関が相次いで発信したメッセージに共通するのは、管理対象の把握と、自社の境界を越えたセキュリティ対策の必要性です。

PHP騒動で、委託先管理の担当者が奔走した2週間

注意喚起ラッシュの後に明らかになった「PHP2Shell」の脆弱性問題は、この課題を最も分かりやすい形で突きつけました。

PHPは、Webアプリケーションやソフトウェア製品などで広く利用されているプログラミング言語です。Webサイトや業務システムだけでなく、VPN機器やセキュリティアプライアンス製品のWebインターフェースなど、さまざまな製品・サービスにも組み込まれています。

今回のPHP2Shellは、2つの脆弱性（CVE-2026-109618、CVE-2026-109619）の通称です。悪用された場合、認証されていない遠隔の第三者によって任意のコードを実行される可能性がある深刻な脆弱性です。

PHP 8.2系では8.2.35未満、8.3系では8.3.36未満、8.4系では8.4.27未満、8.5系では8.5.12未満のバージョンが影響を受けます。

今回の脆弱性は、Wiz社の調査によると、PHP 5.4以降のバージョンは、2つの脆弱性の少なくとも一方の影響を受けるとされています。

PHP 8.1以前はすでにPHPの開発元のサポートが終了しています。ただし、今回のPHP2Shellについては例外的に、PHPの開発元が7.4・8.0・8.1向けに最小限の修正コードを、PHP公式GitHubリポジトリのブランチ上で公開しています。これは正式な修正版リリースではなく、ソースコードからビルドする場合などに利用する修正コードです。

一方、LinuxディストリビューションやLTSベンダーなどから、独自に修正を適用したパッケージが提供される場合もあります。修正の提供状況は、利用しているOSベンダーや、製品・サービスの提供元に確認する必要があります。

自社で開発・運用しているシステムであれば、開発部門やシステム管理部門に確認することで、利用状況を把握できますが、利用状況の調査や影響範囲の特定・修正対応には相応の時間と手間がかかります。

そして、今回さらに負担が大きかったのは、グループセキュリティ、委託先管理、TPRM（サードパーティリスク管理）を担当する方々だったはずです。

• 「グループ各社と主要な委託先（サードパーティ）に対して、PHPの利用有無と対応状況を確認し、報告してほしい」

このような調査・報告指示を受けたセキュリティ担当者は、とても苦労したのではないでしょうか。

まずは、システム一覧、委託先管理台帳、構成・資産管理情報、契約書、過去のメールなど、社内に散在するさまざまな情報を確認し、調査対象となる組織や担当者を特定しなければなりません。そのうえで、対象となるグループ会社や委託先に個別に連絡し、メールで確認を依頼したり、質問票を作成して数十から数百の組織に一斉送付することになります。

今回は緊急性の高い脆弱性であったため、回答期限も短く設定せざるを得ません。依頼する側も、回答する側も、限られた時間の中で複数の対応に追われることになります。

さらに、グループ会社や委託先から戻ってくる回答も一様ではありません。「現在確認中」「担当者が不在」「利用していないはず」「対象システムが分からない」など、回答の内容や確度はさまざまです。そもそも、誰に確認すればよいのか分からないケースもあれば、海外拠点からは期限までに回答が戻ってこないケースもあったはずです。

ここで注目したいのが、IPAによる事前の注意喚起です。IPAは、製品や機器の内部でのPHPの利用状況について、「利用者側では把握できない場合があります」と指摘しています。つまり、自社で管理しているシステムであっても、利用しているソフトウェアや製品の内部まで含めると、すべてのPHPの利用状況を抜け漏れなく把握できるとは限らないのです。

ましてや、グループ会社や委託先、その先のサプライチェーンまで含めて考えた場合、自己申告による調査だけで利用状況や影響範囲を漏れなく把握することには、構造的な限界があります。

今回のPHP2Shellは、緊急時の脆弱性対応という個別の問題にとどまらず、サプライチェーン全体のIT資産やソフトウェアの利用状況を、平時からどこまで把握できているのかという、グループセキュリティ・TPRMの根本的な課題を浮き彫りにしたのではないでしょうか。

なぜ、従来のやり方では間に合わないのか

これまでの資産管理は、台帳と質問票、そして年に1〜2回の脆弱性診断やペネトレーションテストなどが中心でした。この方法には3つの限界があります。

従来のやり方の3つの限界

1つ目は「台帳に載っていないものは管理されない」こと。部署が独自に立ち上げたキャンペーンサイト、開発やPoC向けに作ったまま消し忘れたサブドメイン、海外子会社が現地で契約したサービス。いわゆる本社視点から見たシャドーITは、そもそも台帳に載りません。

2つ目は「自己申告は時間を要するが、必ずしも正確とは限らない」こと。質問票は委託先のセキュリティ体制を評価するうえで欠かせませんが、緊急時に「どのURLで、どのソフトウェアが動いているか」を即座に答えてもらう道具としては向いていません。

3つ目は「攻撃のスピードに追いつけない」こと。これはフロンティアAIリスクの一環であり、攻撃側が公開された脆弱性を実用化するまでの期間が1.7日、防御側が危険度の高い脆弱性にパッチを当てるまでの期間が55日というデータもあるほどです^[i]。対象からの回答を待っているあいだに、攻撃者は先に答えを見つけてしまいます。

[i]攻撃側と防御側の数値は、それぞれ異なる調査・定義に基づくものであり、単純な所要時間の比較を示すものではありません。

ASMとは：攻撃者と同じ「外からの目線」を持つこと

こうした課題に向き合う考え方の一つに、ASM（Attack Surface Management）があります。ASMは、インターネットからアクセスできる自組織のIT資産、すなわち「攻撃対象領域（アタックサーフェス）」を外から探索・特定し、リスクを継続的に評価する取り組みです。

台帳から出発するのではなく、攻撃者と同じように外から自社を眺める。そうすることで、台帳に載っていない資産も、委託先が運営している自社名義のサイトも、同じ土俵で見つけられる可能性が高まります。

9機関の注意喚起が求めている「外部公開資産の洗い出し」「不要な公開の停止」「サプライチェーン全体のリスク把握」は、ASMが対象とする領域と重なります。

改善の第一歩は「減らす」こと：ECRSで考える攻撃対象領域

業務改善のシーンでよく使われるフレームワークとしては、ECRS（イクルス）が有名です。

頭文字の順に検討します。大切なのはこの順番です。

これを攻撃対象領域に当てはめると、次のようになります。

ECRSで考える攻撃対象領域

1. Eliminate（なくす）：終了したキャンペーンサイト、消し忘れた開発環境、解約済みサービスを指したままのDNSレコード、外に出ている管理画面や不要なポートを閉じる
2. Combine（まとめる）：部署ごとに散らばったドメインやサイトを集約し、管理の窓口を一つにする
3. Rearrange（入れ替える）：グループ会社や委託先との役割分担を見直し、「誰が守るか」をはっきりさせる
4. Simplify（単純にする）：利用するソフトウェアやバージョンを標準化し、パッチ適用を楽にする

なかでも効果が大きいのがEliminate（なくす）です。閉じたサイトは、新しい脆弱性が公表されても攻撃されず、パッチも影響調査も不要です。PHP騒動で確認対象になったサイトの中にも、本来はもう存在しなくてよいものが少なからずあったはずです。

NCOが「利用していないシステムや機能は停止・削除する」を、JPCERT/CCが不要な公開の停止を求めているのも、同じ発想です。

不要なものを丁寧に守り続けることほど、効率の悪い努力はありません。

20年以上前の話になりますが、1990年代後半から2000年代前半にかけて、個人情報の漏えい事案が相次ぎました。こうした事案やIT化の進展などを背景に、個人情報保護の重要性が社会的に高まり、2003年に個人情報保護法が成立、2005年に全面施行されました。

その後、セキュリティコンサルタント同士で、個人情報保護法への対応がうまく進んだお客さまと、苦労されたお客さまには、どのような違いがあるのかを議論・検証したことがあります。

そこで最も顕著な違いとして挙がったのが、そもそも個人情報を減らせないか、なくせないかを検討し、実行していたかどうかでした。

Eliminate（なくす）を徹底し、守るべき個人情報の質と量を適正化できていたお客さまほど、その後の管理・運用を合理的に進めていました。

個人情報保護とAttack Surface Managementには、管理対象となる多種・大量の情報や資産を把握し、継続的に管理するという共通点があります。

「何をなくせるか」は条件次第

もし、ある企業がECRSの重要性を認識し、Eliminate（なくす）を徹底しようと決断したとき、とても大事なポイントがあります。

それは、「存在を知らないものは消せない」という圧倒的な現実です。「何をなくせるか」は、攻撃対象領域の全体が見えて初めて正しい判断ができます。

インターネットの攻撃対象領域に対する改善のスタート地点として、ASMによる企業のサプライチェーン全体の一斉把握が有効です。

見落とした資産は「なくす」候補に挙がりません。今回の注意喚起とPHP2Shell対応から見えてくるのは、外部公開資産を「広く」探すことと、「深く」確認することの両方が必要だという点です。

「広く」「深く」自社サプライチェーンの攻撃対象領域を把握する

ASM（Attack Surface Management）を活用するうえで重要なのは、単に外部公開資産を見つけることではありません。自社のサプライチェーンが保有する資産を広く把握し、それぞれのシステムでどのような技術が使われているかを深く捉え、必要な対応につなげることです。

広く：グループ会社や未知のドメインまで把握する

企業の外部公開資産は、必ずしも情報システム部門が把握しているものだけとは限りません。グループ会社が独自に取得したドメイン、事業部門が企画したキャンペーンサイト、過去のプロジェクトで利用したWebサイトなど、組織内で十分に管理・共有されていない資産が存在することがあります。

また、システムの運用を外部委託している場合、委託先が管理するドメインやWebサイトが、自社の事業やブランドと関係していても、社内からは把握しにくいことがあります。

こうした資産を把握するには、既知のドメインやIPアドレスを起点にするだけでなく、ドメインの管理者情報、企業名やブランド名との類似性、Webサイト間のリンク関係など、複数の手掛かりから探索することが有効です。

外部から観測できる情報を組み合わせることで、従来の資産管理台帳には記載されていなかったドメインやWebサイトを発見できる可能性があります。

ただし、発見された資産が本当に自社やグループ会社に関係するものなのか、また、現在も管理・運用されているものなのかを確認することも重要です。探索範囲を広げるだけでなく、検出した資産の帰属を適切に判断することが求められます。

深く：「どのURLで、何が動いているか」まで把握する

外部公開資産を広く把握することは重要ですが、それだけでは十分ではありません。

PHP2Shellのような脆弱性が公表された際に必要なのは、「自社に関係するWebサイトが存在するか」だけでなく、「そのサイトのどこでPHPが使われているか」という、より具体的な情報です。

一般に、Webサイトのトップページから取得できる情報だけでは、サイト内のすべての技術構成を把握できるとは限りません。たとえば、トップページとは異なるアプリケーションが、/user/login や /shop/search といった下位のURL階層で稼働している場合があります。

そのため、Webサイト内の複数のURLを調査し、それぞれで利用されているソフトウェアや技術の情報を深く把握することが重要になります。

こうした情報を一覧化できれば、特定のソフトウェアに関する脆弱性が公表された際にも、該当する技術が外部から観測できるWebサイトやURLを絞り込み、影響確認の優先順位を付ける手掛かりになります。

PHPの利用状況を確認する場合であれば、外部からPHPの利用が推定・観測できるURLを検索し、該当するサイトの管理部門や運用委託先に確認する、といった対応が考えられます。

数百社に一斉に質問票を送って回答を待つ前に、外部から得られる情報を活用して確認対象を絞り込むことができれば、影響調査の初動を効率化できます。

また、同じ考え方は、外部ドメインから読み込んでいるJavaScriptなどの外部スクリプトの把握にも応用できます。参照先のサービスが侵害された場合、自社のどのWebサイトがそのサービスを利用しているのかを確認する手掛かりになります。

さらに、解約済みの外部サービスを指定したままのDNSレコードなど、サブドメインテイクオーバー（サブドメイン乗っ取り）につながる可能性のある忘れられたDNS設定を把握することも、外部公開資産を管理するうえで重要な観点です。

ASM後の改善アクション：誰が管理し、誰が対応するのか

外部公開資産を発見しても、それだけでセキュリティリスクが解消されるわけではありません。
ASMの運用で難しいのは、発見した資産について、誰が管理しているのか、誰に対応を依頼すればよいのかを特定することです。

たとえば、グループ会社が管理するWebサイトであれば、グループ会社のどの部門が担当しているのかを確認する必要があります。外部委託先が運用している場合には、委託先との契約や管理責任の所在を確認しなければなりません。

また、すでに利用されていないWebサイトであれば、単に脆弱性への対処を依頼するのではなく、サイトの廃止や公開停止を検討することも必要です。

このように、ASMで検出された情報を実際のアクションにつなげるには、資産の技術的な情報だけでなく、管理組織や担当者といったステークホルダーと、その対応状況を整理することが欠かせません。

経営層、セキュリティ統括部門、グループ会社、システム管理者など、それぞれの立場に応じて必要な情報を整理し、対応を依頼できる仕組みを整えることが、ASMを継続的に運用するためのポイントです。

外部からの観測でわかること、わからないこと 

ASMに携わってきた立場から、一つ正直にお伝えしたいことがあります。

• 『ASMは魔法の杖ではありません。』

ASMで行う外部からの調査は、基本的にインターネット上から観測できる情報を収集・分析するものです。そのため、外部から見えない情報まで把握できるわけではありません。

また、外部からソフトウェアの利用が推定できたとしても、正確なバージョンや脆弱性の有無まで必ず確認できるわけではありません。実際の影響範囲を特定するには、システム管理者への確認や、必要に応じた脆弱性診断など、別の調査手段が必要になります。

だからこそ、複数の手段を組み合わせることが大切です。

ASMで外部から観測できる資産や技術情報を把握し、優先度の高い対象については、質問票による確認、構成管理情報やSBOM（ソフトウェア部品表）の確認、脆弱性診断などを組み合わせて調査する。こうすることで、それぞれの手段の限界を補いながら、より実態に即したリスク評価が可能になります。

特にサプライチェーン全体のセキュリティを考える場合、委託先や取引先からの自己申告だけに依存するのではなく、外部から観測できる客観的な情報も活用することが重要です。

ASMは質問票や従来のセキュリティ評価を置き換えるものではありません。自己申告による情報と外部からの観測情報を組み合わせることで、確認すべき対象を見極め、限られたリソースをより重要なリスクへの対応に振り向けることができます。

おわりに：「見えないものは守れない」

日頃から懇意にしている大手企業の技術に明るいCISOが、直近1年間で何度も繰り返してきた言葉があります。

『見えないものは守れない』

企業が守るべき対象は、自社が把握しているシステムだけとは限りません。グループ会社、委託先、取引先、さらには過去に構築されたWebサイトなど、組織の境界を越えて、さまざまな資産が事業とつながっています。

一方、攻撃者も公開されている情報を手掛かりに、企業が十分に把握できていない資産やシステムを24時間・365日探索しています。フロンティアAIの急激な進化によって、こうした探索や攻撃のスピードがさらに加速する可能性は高いです。

今回はPHPでしたが、次の大型脆弱性が公表されたとき、「自社のサプライチェーン全体のどこで、そのソフトウェアが使われているのか」に、どれだけ早く答えられるでしょうか。

有事対応における質と速度は、有事が起きる前の備えで決まります。

自社の資産を把握し、不要なものを減らし、本当に守るべきものを明確にする。そのための第一歩として、まずは自社の外部公開資産を見直してみてはいかがでしょうか。

ASMの導入でつまずきやすいポイントや、フロンティアAI対策、サプライチェーン対策、TLPT（脅威ベースのペネトレーションテスト）準備、外部からの指摘への対応、PQC（耐量子計算機暗号）移行準備という5つの活用シーンを、ホワイトペーパー「失敗しないための『ASM実践ユースケース』」にまとめています。

自社の現状を整理し、今後のセキュリティ対策を検討する際の参考資料として、ぜひご活用ください。

• 参考資料

• 失敗しないための「ASM実践ユースケース」

• 自社やグループ会社の外部公開資産をどこまで把握できているでしょうか。
  ASMの導入でつまずきやすいポイントと、2026年に押さえておきたい5つの活用シーンを1冊にまとめました。

• ・9機関の注意喚起が示す「境界崩壊」と「セキュリティ盲点」の正体

  ・脆弱性の武器化1.7日 vs パッチ適用55日：AI時代に防御側が取るべき優先順位

  ・ASM導入で失敗する企業に共通する4つの特徴と、その回避策

  ・サプライチェーン統制を「質問票＋外からの客観評価」へ進化させる方法

  ・フロンティアAI対策／委託先・取引先の安全確保／TLPT前のターゲット絞り込み／外部からの指摘への対応／PQC移行準備の5ユースケース
  
  

  ▶ ホワイトペーパーをダウンロードする

＜関連サービス＞
負担の少ない、やさしいASM｜ASMソリューション ASMimosa