Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年8月11日に Ivan Evsyukovが投稿したブログ (https://www.sysdig.com/blog/vulnerability-response-in-the-ai-discovery-era) を元に日本語に翻訳・再構成した内容となっております。
AI がチームの修正速度を上回るペースで脆弱性を発見できるようになると、何が変わるのでしょうか。そして、それに対処するための4部構成のプランをご紹介します。
フロンティア AI モデルは今や、人間では太刀打ちできない規模とスピードで脆弱性を発見できるようになりました。現時点でその最高到達点にあるのが Mythos です。そこには、CVE が割り当てられていない欠陥や、何十年もレビューされ続けてきたコードに潜む欠陥も含まれます。現在、最も強力なモデルへのアクセスは制限されていますが、その能力は広がりつつあり、攻撃者もそれを手にします。
ここに実務上の問題があります。脆弱性の発見は高速かつ低コストになりました。しかし、そのトリアージ、修正、そして悪用されたものの封じ込めは、そうなっていません。すでにバックログが滞っているプログラムであれば、状況はさらに悪化します。そこで本記事では、実際に何が変わるのか、そして追いつけるプログラムをどう構築するのかを見ていきます。
前提条件に起きた4つの変化
1. 既存の機関が処理できる量を超える脆弱性が生まれている。 CVE の発行は AI が発見できる量に追いつかず、実在する検出結果の一部には CVE が一切付かないままになります。CVE があるかどうかに関わらず、それが実際のビジネスリスクを表しているのであれば、対処する責任は自チームにあります。
2. 攻撃者にとってエクスプロイトはより速く、より安価になる。 脆弱性が知られてから悪用されるまでの時間は劇的に短縮しました。Mandiant の最新の M-Trends レポートでは、平均の time-to-exploit（悪用までの時間）をマイナス7日と見積もっています。つまり、パッチが存在する前から悪用が始まっているということです。レスポンスと修正対応の時間も、それに合わせて短縮しなければなりません。
3. リスク受容を正当化することが難しくなる。 AI によって防御は速く安価になる、という業界の語り口があります。そのため、修正せずに放置することは、リソースの問題ではなく、ひとつの判断とみなされるようになります。取締役会や監査人は、セキュリティチームが AI を使ってより速く、より安価に運用することを期待するでしょう。攻撃者がそうするからです。
4. アタックサーフェス全体の露出が高まる。 ソフトウェア、設定、アイデンティティの弱点は、いずれもマシンスピードで発見され、探索され得ます。本記事はソフトウェアの脆弱性に焦点を当てていますが、同じ原則は他の一般的な攻撃ベクトルにも広げて適用できます。
明るい材料もあります。特定のコードベースについて言えば、これは一時的な急増であり、終わりのない洪水ではありません。コードは有限であり、AI が見つける欠陥のほとんどは、既知の修正方法がある既知の脆弱性クラスです。難しいのは脆弱性が特異だからではなく、その量です。
新しい状況に向けたプログラムの作り方：4部構成のプラン
このギャップを埋めるのはセキュリティチームの仕事です。攻撃者を助けているのと同種の AI ツールは、防御側も利用できます。トリアージ、修正の振り分け、そしてレスポンスに活用してください。
以下に示すプランが、その実現に役立ちます。このプランの各パートは、その前のパートだけでは不十分だからこそ存在しています。トリアージできる量を超えて発見し、修正できる量を超えてトリアージすることになり、そしてすべてを修正しきることはありません。
1. スキャンして発見する
この最初のステップの目標は、発見されたものすべてが、管理可能なひとつの場所に集まることです。CVE の発見は分かりやすい部分です。重要なアセットがすべて実際にカバーされていることを確認してください。それが1社の非常に網羅的なベンダーによるものでも、複数のソースの組み合わせによるものでも構いません。
新たに必要となる作業は、CVE 以外の検出結果への対応です。スキャンでは、AI が発見した欠陥を含め、CVE カタログの枠を超えた脆弱性データを取り込み、それを他のすべてと同じトリアージおよび修正対応のプロセスに流し込む必要があります。CVE だけを管理するツールは、この新しい種類の検出結果を捉えられません。幸いなことに、修正対応とレスポンスのパターンは変わりません。CVE のない脆弱性も、私たちが修正方法を知っている対象、つまりライブラリ、バイナリ、イメージに紐づいているからです。
2. 優先順位を付ける
AI 以前でさえ、すべてを修正できたのは最も成熟したセキュリティ組織とエンジニアリング組織だけでした。今、適切なトリアージの重要性はさらに高まっています。最終的にすべてを修正すべき SLA 上の理由はあるかもしれませんが、セキュリティの観点では、どの脆弱性が実際にビジネスリスクを増やしているのかを知る必要があります。本当に重要なシグナルは3つあり、うち最初の2つは稼働中の環境でしか測定できません。
- 使用中かどうか。 脆弱なパッケージは実際にメモリにロードされて動作しているのか、それともどこかにインストールされているだけなのか。
- 悪用可能性。 ネットワークアクセス、エクスポージャー、あるいは他の経路を通じて到達可能なのか。
- 影響。 このアセットが侵害された場合、実際にビジネスへの悪影響があるのか。
組織面でのポイントが2つあります。
- この分析が生み出すショートリストにチームを集中させてください。
- トリアージを支援するツールを信頼できる状態にしてください。優先度を下げるというのは能動的な判断であり、チームがそのフィルターを信頼していなければ定着しません。
3. 修正対応する
この量では、修正対応を職人的な手作業で行うことはできません。どこを修正するのか、誰が修正するのか、どう振り分けられるのかは、wiki を掘り返すのではなく、自動化によって答えが出るべきです。
- 根本で修正する。 そこからビルドされたすべてのインスタンスにパッチを当てるのではなく、ベースイメージに一度パッチを当てます。
- オーナーシップと割り当てを自動化することで、手作業の調査なしに検出結果が適切なチームへ振り分けられます。
- 可能な範囲で自動修正を活用する。 生成されたプルリクエストや設定変更によって、パイプラインを通過する修正作業の量を増やせます。
- 本番前でブロックする。 ビジネス上の理由で本番に到達する必要がないものであれば、admission controller かパイプラインで止めてください。それが最も低コストな修正です。
- 他のレバーを把握する。 パッチは発見のペースに追いつかないため、クラウド、ネットワーク、アイデンティティの設定を修正手段として使えるレベルまで理解しておいてください。脆弱なワークロードへのネットワークアクセスを遮断することも修正対応であり、多くの場合パッチを待つより速く済みます。
組織としても、この作業を実際に優先する必要があります。どうやって賛同を得るかは組織によりますが、それは仕事の一部であり、後回しにするものではありません。賛同はビジネス起点の指標と目標によって動き、取締役会から、実際に修正を行うエンジニアリングチームやインフラチームに至るまで、防御戦略を優先させることにつながります。焦点を絞るのに適した問いはこれです。重要な脆弱性は、重要なアセット上でどれだけの期間、露出したままになっているのか。
4. 脆弱性が悪用されることを想定して計画する
すべてを修正することはできません。リソースの問題である場合もあります。修正が存在しない場合や、修正によって大量の依存関係が壊れる場合もあります。露出したままになるすべてのものについて、ランタイムがセーフティネットになります。
良いニュースは、侵入口がどれほど新しいものであっても、ポストエクスプロイトの挙動は似通っているということです。権限昇格、偵察、鍵の取得です。攻撃者を捕まえるために、エクスプロイトそのものを認識する必要はありません。エクスプロイトからビジネスへの影響が生じるまでの間の時間こそ、組織を実質的に守れる領域です。
実務上は次のとおりです。
- ワークロードを監視して侵害の痕跡（IoC）を捉える。 データの持ち出し、不審な偵察、マルウェアの活動です。
- どれだけ速く検知できるか、そしてより重要な、どれだけ速くレスポンスできるかを測定する。そして、ボトルネックを見つけてください。データの処理が十分に速くない、人の確認が十分に速くない、あるいは確認すべき対象が多すぎる、といったものです。これらのボトルネックはいずれも、ツールかプロセスで解決できます。検出結果が多すぎる場合や時間外のカバレッジが不足している場合は、AI エージェントを活用してください。データやエンリッチメントのパイプラインが遅すぎる場合は、レスポンスをデータソースに近づけてください。
- 実用的な封じ込めプレイブックを作る。 何を自律的に実行でき、何に人間の判断が必要かを、あらかじめ決めておいてください。エスカレーションの経路を定義します。
- 事業部門への通知プロセスを整備する。インシデントの最中ではなく、チームが破壊的なアクションを取る必要に迫られる前に行ってください。
- 必要な量やスキルが自チームの手に余る場合は、補完する。サービスプロバイダーやエージェント型 SOC のツールを活用してください。
まとめ
ここに新しいものは何もありません。カバレッジ、トリアージ、産業レベルの修正パイプライン、そしてすり抜けてきたものに対する実効性のあるプランです。変わったのは、AI が両側で賭け金を引き上げたという点です。攻撃者はより多くを、より速く見つけますが、防御側も同じツールを利用でき、それを効果的に活用する術を学ばなければなりません。発見はスケールしました。次はレスポンスがそれに追いつく必要があります。