AIが脆弱性管理を変える：Mythos以後の企業セキュリティ運用
この記事の位置づけ
本稿は、Anthropic の Project Glasswing と Mythos Preview、Cloudflare による検証結果、Qualys や Tenable が発信している「Post-Mythos」「Mythos-ready」の論点を踏まえ、企業側の脆弱性管理が何を変えるべきかを整理する記事です。1234
ここで扱う Mythos は、特定ベンダーの製品評価ではなく、AIが脆弱性発見、検証、悪用可能性評価、修正優先度付けに深く入ってくる時代を象徴する事例として扱います。2026年5月23日時点では、Project Glasswing の詳細な技術情報は、協調的脆弱性開示の都合でまだ限定的です。そのため、本稿では公表済みの集計値や各社の運用上の示唆をもとに、企業の対応モデルへ引き直します。1
要旨
AIの進化により、脆弱性管理は大きな転換点に入りつつあります。
従来、未知の脆弱性は人間の研究者、バグバウンティ、ベンダー診断、SAST/DAST、ペネトレーションテストなどにより発見されてきました。自動解析技術は以前から存在しましたが、発見、検証、PoC作成、攻撃経路の構築には、一定の人間の専門性と時間が必要でした。
Mythos Preview に象徴されるAI支援の脆弱性発見能力が現実味を帯びると、この前提が変わります。Anthropic は、Project Glasswing の初期更新で、パートナー各社が多数の高・重大脆弱性を発見し、Cloudflare では重要経路システム全体で2,000件のバグ、そのうち400件が高・重大とされたと説明しています。さらに、OSSスキャンでは1,000超のプロジェクトから多数の候補を発見し、人手による検証がボトルネックになっていると述べています。1
企業は、次のような変化に向き合う必要があります。
- 脆弱性の発見件数が増える
- CVE公開、PoC公開、悪用開始までの時間が短くなる
- 月次・四半期のパッチ運用では間に合わない場面が増える
- CVSSだけで優先順位を決める運用が限界を迎える
- パッチ適用までの代替防御がより重要になる
- 24時間365日稼働を前提にしてきたシステムでも、緊急停止、縮退運転、外部遮断を選択肢に入れる必要が出てくる
したがって、企業側に必要なのは、単に「迅速にパッチを当てる」体制だけではありません。資産管理、露出管理、SBOM、攻撃経路分析、代替防御、緊急変更プロセス、経営判断、そして「安全に止める」設計まで含めた、セキュリティレジリエンスの再設計です。
全体像
AI時代の脆弱性管理では、情報を受けてから順番に会議を開くのでは遅くなります。自社該当性確認、露出評価、代替防御、監視強化、経営報告を並行して進める運用が必要になります。
Mythosが示している変化
Cloudflare の検証で重要なのは、「AIが脆弱性を見つけた」という単発のニュース性ではありません。より重要なのは、AIが複数の低深刻度のバグをつなぎ、より重大な exploit chain に組み上げられる可能性を示した点です。Cloudflare は、他の frontier model でも同じ underlying bug を見つけることはあった一方、Mythos Preview ではそれらをつないで exploitability まで進む点が変化だったと説明しています。2
これは、防御側にとって大きな意味を持ちます。脆弱性管理で見るべき対象が、個別CVEの深刻度だけではなく、次のような組み合わせへ広がるからです。
- 低・中深刻度のバグの連鎖
- 認証、設定不備、クラウド権限、ネットワーク到達性の組み合わせ
- OSS、商用製品、クラウド設定、社内コードをまたぐ依存関係
- 修正前の暫定回避策を迂回できるかどうか
- 攻撃者が実際に到達できる経路があるかどうか
Cloudflare は同時に、AIによる脆弱性発見にはノイズ問題があるとも述べています。モデルは確信度を人間の研究者のように明確に示すとは限らず、「可能性がある」候補が大量に出るため、検証、再現、優先順位付けの工程が重要になります。2
つまり、AIは万能な脆弱性判定者ではありません。AIが発見候補を増やし、exploitability の検討を速めるほど、防御側には候補を検証し、事業リスクに結び付け、実行可能な対応へ落とす能力が求められます。
脆弱性洪水への対応
AIにより脆弱性発見件数が増える場合、問題は「見つけられること」ではありません。見つかった大量の脆弱性候補の中から、自社にとって本当に危険なものを選別できるかです。
Qualys は Post-Mythos era の論点として、手作業のチケット駆動から、検証済み脆弱性に対する自律的な修復運用へ移る必要があると整理しています。特に、ノイズを大幅に減らす hyper-prioritization、ゼロデイ修復、AI-speed detection を一つのループとして扱う必要があると述べています。3
Tenable も、Mythos-ready な組織には、継続的な資産発見、従来のスコアリングを超えたリスクフィルタ、attack path analysis、agentic remediation が必要だと述べています。特に、CVSSやEPSSだけではなく、攻撃経路と業務重要度を組み合わせて絞り込むことを重視しています。4
企業側の優先順位付けでは、少なくとも次の観点を合わせて見る必要があります。
| 観点 | 確認する問い |
|---|---|
| 存在 | 該当製品、ライブラリ、設定、コードが自社に存在するか |
| 露出 | インターネット、取引先、社内ネットワーク、クラウド管理面から到達できるか |
| 悪用 | 実悪用、PoC、exploit chain、認証不要性、RCE性があるか |
| 重要度 | 重要業務、機微情報、ID基盤、決済、管理系に関係するか |
| 横展開 | 侵害後に権限昇格、横展開、クラウド権限取得につながるか |
| 補完統制 | WAF、IPS、EDR、セグメンテーション、権限管理で抑えられるか |
| 変更影響 | パッチ適用、設定変更、停止、縮退の業務影響はどれくらいか |
この整理は、vulnerability management から exposure management への移行として捉えると分かりやすくなります。脆弱性単体ではなく、自社環境で攻撃者が実際に使える露出として評価するということです。
CVSSだけでは足りない
CVSSは今後も必要です。脆弱性そのものの一般的な深刻度を把握する標準指標として有用です。しかし、AI時代の脆弱性洪水では、CVSSだけで対応順を決める運用は危うくなります。
企業側が本当に知りたいのは、次のような問いです。
- この脆弱性は自社環境に存在するのか
- その資産はインターネットから到達可能か
- 認証なしで悪用できるのか
- 既に実悪用されているのか
- PoCは公開されているのか
- 攻撃者が関心を持つ製品や資産か
- そのシステムは重要業務に関係するのか
- 侵害された場合、横展開できるのか
- WAF、IPS、EDR、セグメンテーションで抑えられるのか
- パッチ適用時の業務影響はどの程度か
CISA の Known Exploited Vulnerabilities Catalog は、実際に悪用が確認された脆弱性を優先的に扱う考え方を示す代表例です。BOD 22-01 は米国連邦文民機関向けの指令ですが、CISA はすべての組織に対して、KEV掲載脆弱性を優先的に修正することを推奨しています。5
また、FIRST の EPSS は、今後30日以内に脆弱性が実悪用される確率を推定するスコアリング体系です。CVSSが脆弱性の特性を示すのに対し、EPSSは実悪用可能性の予測に寄せた指標として使えます。6
ただし、KEVやEPSSも万能ではありません。自社の露出、業務重要度、補完統制、攻撃経路を合わせて見なければ、現場で直すべき順序にはなりません。
パッチだけでは足りない
パッチ適用は最も重要な恒久対応です。しかし、現実には次の制約があります。
- ベンダーから修正版がまだ出ていない
- パッチを当てると業務影響が大きい
- 24時間365日稼働で停止調整が難しい
- OT、IoT、医療機器、ネットワーク機器など、簡単に更新できない
- 依存ライブラリが複雑で影響範囲が分からない
- パッチ適用後のテストに時間がかかる
- レガシーシステムで保守切れになっている
このため、パッチ適用までの間に、どの統制で止血するかが重要になります。
| 対象 | 代替防御の例 |
|---|---|
| Webアプリ | WAF仮想パッチ、該当URL遮断、パラメータ制限、レート制限、Bot対策、feature flag停止 |
| 管理画面 | IP制限、認証追加、VPN経由化、外部公開停止、特権操作の一時停止 |
| クラウド | Security Group制限、IAM権限縮小、公開バケット閉塞、管理API制限、脆弱コンテナ停止 |
| エンドポイント | EDR検知強化、隔離、アプリ制御、ローカル権限縮小 |
| ネットワーク機器 | 管理面遮断、ACL強化、セグメンテーション、代替機切替、監視強化 |
| OT/IoT | 外部通信遮断、ジャンプサーバー制限、ネットワーク分離、運転影響を踏まえた段階的更新 |
重要なのは、緊急時に初めて代替防御を考えないことです。システム類型ごとに、使える統制、担当者、承認者、想定業務影響、ロールバック手順を事前に持っておく必要があります。
24時間365日稼働前提の揺らぎ
本稿で特に重要視したいのは、24時間365日稼働を当然としてきたシステム運用の前提が揺らぐ可能性です。
これまで多くの企業では、重要システムほど「止めない」ことが重視されてきました。金融、通信、EC、医療、公共、製造、物流などでは、停止は業務影響、顧客影響、社会影響に直結します。そのため、パッチ適用も定例メンテナンス枠に押し込められ、緊急停止は極力避けられてきました。
しかし、AIにより脆弱性の発見と悪用可能性評価が高速化すると、この考え方は再検討を迫られます。
例えば、認証不要RCEのような重大脆弱性が公開され、PoCも存在し、インターネットから到達可能で、WAF等の補完統制でも十分に抑えられない場合、システムを稼働し続けること自体が重大なリスクになります。
このとき、企業は次の問いに答えなければなりません。
- 業務継続のために動かし続けるべきか
- 情報漏えいや侵害拡大を避けるために止めるべきか
- 全停止ではなく、一部機能停止で済むか
- 外部公開だけ止めて、内部業務は継続できるか
- 片系運転や縮退運転は可能か
- 停止判断は誰が下すのか
- 顧客、取引先、監督当局への説明はどうするのか
今後は、セキュリティ上の理由で意図的に止める、絞る、遮断する、縮退する能力そのものが、レジリエンスの一部になります。重要システムは「絶対に止まらないシステム」ではなく、「必要なときに安全に止められるシステム」である必要があります。
企業に必要な対応
資産管理の再整備
AI時代の脆弱性対応の前提は、正確な資産把握です。脆弱性情報が来たときに、自社のどこに該当製品、該当ライブラリ、該当設定が存在するのか分からなければ、対応は始まりません。
最低限、次の情報は整備しておく必要があります。
- システム名
- システムオーナー
- 運用担当
- セキュリティ担当
- 業務重要度
- インターネット公開有無
- 利用OS、ミドルウェア、フレームワーク
- OSS依存関係
- SaaS/API連携
- ネットワーク到達性
- 認証方式
- WAF、IPS、EDR等の保護状況
- パッチ適用責任者
- 停止可否
- 緊急連絡先
- 代替防御手段
特に重要なのは、インターネット公開資産、ID基盤、VPN/リモートアクセス、管理画面、クラウド管理系、CI/CD、ソースコード管理、コンテナ基盤です。これらは攻撃者にとって価値が高く、侵害時の影響も大きくなります。
SBOMと依存関係管理
AIによりOSSやライブラリの脆弱性が大量に発見される場合、SBOMや依存関係管理の重要性はさらに高まります。ただし、SBOMを作るだけでは不十分です。
必要なのは、次のような運用です。
- どのシステムがどのライブラリを使っているか分かる
- 脆弱なバージョンを即時に検索できる
- 直接依存と推移的依存を把握できる
- コンテナイメージやIaCにも対応できる
- 修正バージョンへの影響を確認できる
- パッチ適用不能時の代替防御を判断できる
- 「なぜ該当しないと判断したか」を後から説明できる
SBOMは、単なる棚卸し資料ではなく、緊急時の該当性判定と監査証跡の基盤です。
リスクベースの優先順位付け
脆弱性の件数が増えるほど、すべてを同じ速度で修正することは不可能になります。企業は明示的なトリアージ基準を持つ必要があります。
優先度を上げる条件は、例えば次の通りです。
- 実悪用が確認されている
- PoCが公開されている
- インターネットから到達可能
- 認証不要で悪用可能
- RCEである
- 認証回避である
- 権限昇格につながる
- 横展開に使える
- 重要業務システムである
- 機微情報を扱う
- WAF、IPS、EDRで抑えにくい
- 攻撃者が狙いやすい製品である
一方で、CVSSが高くても、自社環境で到達不可能であり、補完統制が有効であり、業務影響も限定的であれば、即時対応の優先度は下がる場合があります。この判断を属人的に行うのではなく、基準化し、証跡化することが重要です。
緊急変更プロセス
AI時代の脆弱性対応では、通常の変更管理プロセスだけでは遅すぎる可能性があります。通常CAB、月次会議、四半期計画、長い稟議フローでは、悪用速度に追いつけない場面が出ます。
緊急脆弱性に対しては、通常変更とは別のプロセスを用意する必要があります。
- 脅威情報を受領する
- 30分以内に一次判定する
- 2時間以内に自社該当性を確認する
- 代替防御を即時判断する
- システムオーナーへ通知する
- 緊急変更を承認する
- パッチ適用、設定変更、外部遮断、機能停止を実施する
- 監視を強化する
- 経営へ報告する
- 恒久対応計画を立てる
- 事後レビューを行う
時間は組織やシステム重要度に応じて調整すべきですが、重要なのは「緊急時に初めて関係者を集める」状態を避けることです。平時に判断権限、承認条件、実作業者、連絡経路を決めておく必要があります。
代替防御の標準メニュー化
パッチできない場合に備え、代替防御を事前にメニュー化します。Webアプリ、API、SaaS、クラウド、ネットワーク機器、エンドポイント、OT/IoT、ID基盤など、システム類型ごとに使える手段は異なります。
標準メニューには、少なくとも次を含めます。
- 実施できる統制
- 実施に必要な権限
- 担当チーム
- 承認者
- 想定業務影響
- 監視項目
- ロールバック手順
- 顧客通知や社内通知の要否
このメニューがあると、緊急時に「パッチできるか、できないか」だけで詰まらず、パッチまでの時間をどう埋めるかを判断できます。
2線・統制部門の観点
この変化は、SOCやIT運用だけの問題ではありません。2線、リスク管理、内部統制、監査対応の観点でも大きな意味を持ちます。
従来の問いは、比較的単純でした。
- パッチは期限内に適用されていますか
- 脆弱性診断は実施していますか
- 高リスク脆弱性は是正されていますか
- 例外は承認されていますか
AI時代には、問いを変える必要があります。
- 重大脆弱性の情報を何分・何時間以内に把握できますか
- 自社該当性をどのように判定していますか
- 外部露出と攻撃経路を把握していますか
- パッチできない場合の代替防御はありますか
- 緊急停止や縮退運転の判断基準はありますか
- システムオーナーと事前合意していますか
- 対応優先順位の根拠を説明できますか
- 侵害痕跡を確認しましたか
- 経営に報告すべき条件は定義されていますか
統制証跡としては、次のようなものが必要になります。
- 資産台帳
- SBOMまたは依存関係一覧
- 脆弱性情報の受領記録
- 自社該当性判定記録
- exploitability 判定記録
- 優先順位付け根拠
- パッチ適用記録
- パッチ未適用理由
- 代替防御の設定証跡
- WAF、IPS、EDRログ
- 緊急変更承認
- システムオーナー合意
- 経営報告資料
- 事後レビュー記録
これらは、単なる監査対応のためではありません。緊急時に組織が説明可能な判断をするための土台です。
安全に止める設計
今後の重要論点として、「安全に止める」設計を明示的に扱う必要があります。
従来、停止は障害、失敗、回避すべき事態として扱われがちでした。しかし、AI時代の脆弱性対応では、止めることが最善のリスク低減策になる場合があります。
例えば、次の条件が重なる場合です。
- 認証不要RCEである
- PoCが公開されている
- インターネットから到達可能である
- 修正版がない、または適用に時間がかかる
- WAF等で十分に防げない
- 侵害時の影響が重大である
- 機微情報や重要業務に関係する
この場合、サービス継続による便益よりも、侵害リスクの方が大きくなる可能性があります。そのため、企業は次のような選択肢をあらかじめ設計しておく必要があります。
- 全停止
- 一部機能停止
- 外部公開停止
- 管理機能のみ停止
- 読み取り専用化
- 片系運転
- 縮退運転
- 代替チャネルへの誘導
- メンテナンス画面への切替
- 顧客・取引先への通知
これはBCPやDRの延長線上にありますが、従来の災害・障害対応とは少し異なります。セキュリティ脅威を理由に、意図的にシステムの露出や機能を下げる設計です。
今すぐ準備すべきもの
企業が今すぐ準備すべきものは、次の5つです。
| 準備物 | 内容 |
|---|---|
| AI時代の脆弱性対応ポリシー | AIにより発見・悪用が高速化する前提、リスクベース対応、緊急停止、代替防御、例外承認、経営報告基準を明文化する |
| 緊急脆弱性トリアージ基準 | 実悪用、PoC、インターネット到達性、認証不要、RCE、重要業務影響、補完統制有無などで即時対応条件を定義する |
| 緊急変更フロー | 緊急判定者、技術評価者、システムオーナー、承認者、実作業者、広報・顧客対応、経営報告、ロールバックを決める |
| 代替防御カタログ | パッチ不能時のWAF、IPS、EDR、IAM制限、外部遮断、機能停止、監視強化をシステム類型ごとに整理する |
| 停止・縮退判断基準 | どの条件なら誰が止める判断をできるのかを、平時に合意しておく |
緊急時に「止めるかどうか」を初めて議論すると、ほぼ間に合いません。平時に、どの条件なら誰が判断し、どの範囲を止め、誰へ説明するのかを決めておく必要があります。
まとめ
Mythos関連の動きが示しているのは、AIによって脆弱性管理の前提が変わるということです。
今後、脆弱性はより多く、より早く、より深く発見される可能性があります。そして、その悪用可能性の検証やPoC化も高速化する可能性があります。
この環境では、企業は従来型のパッチ運用だけでは対応できません。必要なのは、正確な資産管理、SBOMと依存関係管理、exposure management、リスクベースの優先順位付け、緊急変更プロセス、代替防御、パッチ自動化、侵害痕跡確認、経営判断、安全に止める設計の組み合わせです。
特に重要なのは、「止めないこと」を無条件の正義にしないことです。AI時代には、動かし続けることがリスクになる場面があります。逆に、安全に止められること、一部だけ止められること、外部露出だけ下げられること、縮退運転に移れることが、企業のレジリエンスになります。
脆弱性管理は、単なるIT運用ではなく、経営、業務継続、危機管理、内部統制を含むテーマになりつつあります。Mythosは、その変化を象徴する事例です。