Palo Alto NetworksがConsoleを買収、報道額5億ドルは公式未確認
金融・市場 3
脆弱性を常時AIで探すUnit 42、単一モデルは40％未満
Palo Alto Networksは 2026年9月22日付の発表文 で、Unit 42 Continuous Frontier AI Defenseを発表した。企業のWebアプリ、API、クラウド基盤、ソースコードのリポジトリ、ネットワーク資産を継続的に検査し、弱点が実際の攻撃経路になるかを検証するサービスで、世界向けに年額契約で提供される。
複数のAIモデルを作業に応じて使い分け、Unit 42の脅威情報と攻撃検証の専門知識を組み合わせる。同社の 技術解説 によると、企業のコードベースと稼働環境を対象にした自社評価では、どの単一モデルも脆弱性の40％超を検出できず、Claude Mythos 5とGPT-5.6-Cyberが見つけた問題の重なりも10％未満だった。ただし、公表文面の厳密な表現は「40％を超えなかった」であり、見出しの「40％未満」を個別の実測値で確かめられる資料は示されていない。
Axiosの独立報道 も、利用が制限された先端モデルと公開ウェイトのモデルを組み合わせ、顧客環境の変化に合わせて検査を続ける提供内容を伝えた。新サービスの狙いは、発見した弱点を単に列挙することではなく、悪用できるか、別の弱点とつながるかを確かめて修正の優先順位に反映することにある。
継続検査の対象はWebアプリだけではない
検査は、登録された資産の全体を調べる初期調査から始まり、環境の変化に合わせて続く。対象には自社製と外部製のWebアプリやAPIのほか、クラウド基盤、コードのリポジトリ、ネットワーク資産が含まれる。アプリで見つかった問題を、そのアプリの画面やコードだけで判断しないための対象設定だ。
例えば、あるWebアプリの弱点がAPIを通じて別の資産への到達につながるなら、単独の検出結果より影響を具体的に判断できる。これは仕組みを説明する条件付きの例であり、特定の顧客環境でその経路が確認されたという意味ではない。サービスが扱うのは、弱点の発見に加え、複数の資産をまたぐ経路の成立可能性である。
一方、「継続的」という説明だけでは、各資産をどの頻度と深さで試験するかは分からない。初期調査後に環境の変化へ追随するという提供内容と、すべての資産に絶え間なく同じ試験を行うという保証は別だ。日本の運用担当者にとっては、対象の登録方法、変更を検知する条件、認証が必要な領域へのアクセス、本番システムにかける負荷が、実際の検査範囲を決める。
単一モデルの限界を、別のモデルでどう補うか
モデルを増やす理由は、同じ環境を調べても発見する弱点が一致しないためだ。公表された自社評価では、単独のモデルによる検出の上限と、主要モデル同士の発見の重なりの小ささが示された。そこで専用の仕組みが作業を適したモデルへ振り分け、異なる候補を攻撃検証へ渡す構成を採る。
ただし、この評価値から、新サービス全体の検出率を計算することはできない。公開資料には、分母となる脆弱性の選び方、環境の内訳、各モデルの実測値、誤検知率が十分に示されていない。モデル間で結果が重ならないことは補完の余地を示すが、組み合わせれば対象環境の弱点を網羅できるという証明にはならない。
利用できるモデルの組み合わせは契約の選択肢によって異なる一方、いずれの契約でも複数モデルを振り分ける仕組みを使う。したがって、製品名が同じでも、選ぶ契約で使えるモデルや費用条件を確認する必要がある。検出候補をどのモデルが出したかだけでなく、その候補が後の検証を通過したかが、脆弱性管理では重要になる。
発見、再現、攻撃経路の検証は別の判断
このサービスは、候補となる弱点を見つけた後、悪用できるかを確かめ、複数の弱点が連なる攻撃経路を検証する。修正の優先順位は、検出数だけでなく、検証された経路と到達先を踏まえて付ける設計だ。スキャナーが示す候補と、実際に対処を急ぐべき経路を区別することが中核になる。
コード上で疑わしい箇所が見つかっても、稼働環境の設定や必要な権限によっては再現しないことがある。逆に、単独では影響が限られる弱点でも、別の問題とつながれば重要な資産へ到達し得る。こうした違いを判断するには、どの条件で再現し、どこまで到達できたかという根拠が欠かせない。
Unit 42の専門家が関わる提供形態でも、顧客側が試験権限を決める責任は残る。本番環境で許可する手法、試験を止める条件、検証結果を受け入れる基準は、各社のシステムと変更管理に依存する。AIによる発見や経路化を速めることと、業務への影響を伴う試験を無条件で許可することは同義ではない。
修正提案と仮想パッチの適用は分かれている
検証結果に対しては、優先順位を付けた修正案、コードレベルの指針、仮想パッチの推奨が提示される。脆弱性の公表前や正式な修正プログラムの提供前に仮想パッチを適用する場合は、別のFrontier Virtual Patchingと組み合わせる説明になっている。推奨を受け取ることだけで、顧客環境に防御策が自動適用されるわけではない。
仮想パッチは、元のコードや設定の修正とは異なる緩和策だ。検証された経路を遮断できるかに加え、正規の通信を妨げないかも確かめる必要がある。正式な修正を適用した後に制御を残すか解除するかも、対象システムの状態を踏まえた判断になる。
人間の承認を残すべき工程は、試験範囲の設定、影響を伴う再現試験、修正順序の確定、コードや防御設定の変更である。AIが修正案を提示しても、機能への影響、業務通信、変更後の再検証まで自動的に保証されるとは発表されていない。ここは検査サービスの機能と、利用企業の運用上の責任を分けて考える必要がある。
契約前に残る確認事項
発表で明らかになったのは、対象資産の種類、複数モデルによる継続検査、攻撃経路の検証、修正提案、年額提供という枠組みだ。個別の環境でどれだけの弱点を正しく見つけられるか、誤検知がどの程度生じるかは、公表された自社評価だけでは判断できない。導入を検討する企業には、次の点が契約と運用の境界になる。
- 自社製と外部製の資産をどこまで登録でき、認証が必要なAPIや非公開コードにはどの権限でアクセスするのか。
- 検出候補の再現条件、攻撃経路の根拠、誤検知の判定を顧客がどこまで確認できるのか。
- 本番環境への試験を誰が許可し、停止条件と監査記録をどう定めるのか。
- 修正案や仮想パッチの適用を誰が承認し、正式な修正後の再検証をどう行うのか。
新サービスは年額契約で提供され、発見から修正提案までを継続してつなぐ仕組みが示された。ただし、単一モデルの検出値はベンダーの自社評価であり、公開資料は個々のモデルの厳密な実測値や顧客環境での精度を示していない。試験権限と変更承認の具体的な分担も、各社の契約条件と運用設計で確かめる段階にある。
関連記事:
関連記事
ニュースレターを購読
Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。
0