悪用までの猶予が「1分」に迫るフロンティアAI時代に開発と本番を貫く脆弱性管理が必要

　フロンティアAI（最先端AIモデル）の進化により、脆弱性の発見から悪用までの時間が急速に縮まっている。脆弱性のすべてに手を打つのが現実的でなくなる中、企業にはリスクに基づいて優先順位を付け、修正を素早く本番環境へ反映する体制が欠かせない。日本IBM ソフトウェア事業統括 オートメーション・プラットフォーム事業部 オートメーション・プラットフォーム テクニカルセールスの河野 哲也 氏が「インプレス AI Days 2026」（主催：インプレス、2026年9月15日～16日）に登壇し、開発段階と本番環境の両面から脆弱性を管理するモデルの具体像を話した。

　「脆弱性の数が増えているだけではない。即座に悪用されることが問題になっている」――。日本IBM ソフトウェア事業統括 オートメーション・プラットフォーム事業部 オートメーション・プラットフォーム テクニカルセールスの河野 哲也 氏は、フロンティアAI（最先端AIモデル）がセキュリティにもたらした変化をこう指摘する（ 写真1 ）。

写真1：日本IBM ソフトウェア事業統括 オートメーション・プラットフォーム事業部 オートメーション・プラットフォーム テクニカルセールスの河野 哲也 氏

　国内でも危機感は高まっている。金融庁は2026年5月、フロンティアAIによる脅威を踏まえて金融機関に短期的な対応を求めた。脆弱性の発見から攻撃までのスピードと規模が急拡大していることを指摘し、大量の脆弱性やパッチの発生を前提に、資産管理、脆弱性管理、監視体制を経営主導で早急に強化するよう求めている。

　背景にあるのは脆弱性の急増だ。新規に登録されるCVE（Common Vulnerabilities and Exposures：共通脆弱性識別子）は2016年の約6400件から増え続け「2026年には約5万9000件と700%以上増える見込み」（河野氏）だ。増加傾向はフロンティアAIの登場以前から続いていたものの、脆弱性の発見もまたAI技術によってさらに加速している。

悪用までの時間は「1年」から「1分」へと縮まる

　より深刻なのは、脆弱性情報の公開から実際に悪用されるまでの時間（TTE：Time to Exploit）の短縮だ。河野氏が示した予測では、2021年ごろまで「1年」だったTTEは、2025年に「1カ月」、2026年には「1週間」から「1日」へと縮まり、2027年には「1時間」、2028年には「1分」に達する（ 図1 ）。「現時点ですでに、平均29分で悪用されるという数字も出ている」（同）と言う。

図1：脆弱性の公開から悪用までの時間は2028年に「1分」に縮まる

　数が増え、悪用までの猶予も縮む中、河野氏は「すべての脆弱性に対応するのは、もはや現実的ではない」と話す。限られた手数で守るには「事業への影響と悪用リスクに基づいて優先順位を付け、迅速に対応することが重要になる」（同）とする。

「Shift Right」と「Shift Left」を両立させる

　では、具体的にどんな仕組みで実現するのか。河野氏が提示したのが「Shift Right」と「Shift Left」を両立させる脆弱性管理モデルだ。前者は、本番環境のリスクを継続的に監視し、パッチ適用などで是正していく従来型のアプローチを指す。後者は、開発段階でリスクを減らすアプローチだ。同時に進めるのは「AI技術によるコード生成が一般化する一方で、レビューが追い付かず、脆弱性が混入するリスクが高まっている」（同）からだ。

　一方で、現場の脆弱性管理には課題も多い。その現状を河野氏は「スプレッドシートを使った手作業での情報整理に多くの工数が割かれ、何を基準に優先順位を付けるかの判断に迷い、システムごとに分かれた対応状況が組織としてリアルタイムに見えていないケースが目立つ」と説明する。

　こうした課題の解消を狙うのが、SDLC（Software Development Life Cycle：ソフトウェア開発ライフサイクル）全体の保護を担う製品群「IBM Concert」である。中核の「IBM Concert Protect」は、スキャンツールで発見した脆弱性の情報を集約し、影響範囲の特定やリスクの算出、優先順位付けを経て修正へとつなげる。

　まずShift Rightの領域で情報源となるのは、クラウドセキュリティサービス「Prisma Cloud」（米Palo Alto Networks製）やOSS（オープンソースソフトウェア）の脆弱性スキャナー「Trivy」（米Aqua Security製）、脆弱性管理サービス「Qualys」（米Qualys製）や「Amazon Inspector」（米AWS製）といった既存のスキャンツールだ。

　スキャンツールを介して、仮想マシンやコンテナイメージ、ソースコードを対象にした検出結果を用いる。「本番環境か検証環境か、外部に公開されているか、どのシステムと連携しているかといったシステムのコンテキスト（文脈）情報を組み合わせ、優先順位を判断する」（河野氏）という（ 図2 ）。

図2：スキャン結果とシステムのコンテキスト情報を組み合わせて優先順位を判断

　優先順位付けには、Concert独自のリスクスコアを用いる。脆弱性の技術的な深刻度を示すCVSS（Common Vulnerability Scoring System：共通脆弱性評価システム）のベーススコアに、実際に悪用される可能性を評価するEPSS（Exploit Prediction Scoring System：悪用予測評価システム）、アプリケーションの重要性やデータの機密性、ネットワークへの露出度を定量化した環境ファクターを組み合わせる。

　米CISA（Cybersecurity and Infrastructure Security Agency：サイバーセキュリティ・インフラセキュリティ庁）が公開する「KEV（Known Exploited Vulnerabilities：悪用が確認された脆弱性）カタログ」にも対応する。管理画面では、どの脆弱性がどのアプリケーションに影響するかを関係図で示し、生成AI技術を使って脆弱性の詳細や対応方法を調べる機能も備える。

　優先順位を付けた脆弱性へのパッチ適用はローコード／ノーコードの運用自動化ツール「IBM Concert Workflows」で自動化する。河野氏は「ITスキルがそれほど高くない担当者でもパッチ適用を自動化できる」と話す。手動実行やスケジュール実行のほか、API（Application Programming Interface）経由で外部から呼び出し、既存のワークフローシステムやITSM（IT Service Management：ITサービス管理）ツールと連携する使い方にも対応する。OSパッチの適用やコンテナイメージのアップグレードなど、脆弱性対応向けのテンプレートもそろえる。

　一方のShift Leftの領域では、CI（Continuous Integration：継続的インテグレーション）／CD（Continuous Delivery：継続的デリバリー）パイプラインにSAST（静的アプリケーションセキュリティテスト）やDAST（動的アプリケーションセキュリティテスト）を組み込み、その結果をConcert Protectで優先順位付けする。修正は「IBM Concert Secure Coder」が担う。IDE（統合開発環境）と連携し、開発者がコードを書いている最中に、セキュリティ上の問題がある箇所と修正方法を示す。「プルリクエストやパイプラインに進む前に、IDEの中で問題を解決する」（河野氏）わけだ。

　Secure Coderの対象はコードだけではない。ライブラリに潜む既知のCVEを検出し、安全な代替バージョンを推奨する。Concert Protectが把握しているSAST／DASTのリスク情報をIDEへ同期し、該当箇所の修正も促す。リスクスコアは開発者のIDEとConcert Protectのダッシュボードで共通にしている。河野氏は「セキュリティ担当者がConcert Protectで見ている数字と同じ数字を開発者も見ながら、同じ対応ができる」と説明する。

CVE公開前にパッチを先回りして届ける

　Shift Leftを支えるもう1つの柱として河野氏が紹介したのが、IBMと米Red Hatが主導する業界横断の取り組み「Project Lightwell」である。2026年に発表したもので、商用サポートのないOSSを対象に、フロンティアAIが発見した脆弱性の特定と是正を図るものだ。「CVEが公開される前に脆弱性のパッチを提供できるのが特徴」（河野氏）であり、総額50億ドルが投じられ、2万人を超える専任エンジニアが参加する。

　Lightwellの情報やパッチはIBM Concertを通じて提供される（ 図3 ）。Concertで可視化・優先順位付けしたうえで適用を決めたパッチは、Concert Workflowsを介して構成管理・自動化ツール「Red Hat Ansible」（Red Hat製）やインフラ構築ツール「Terraform」（米HashiCorp製）、マシンイメージ作成ツール「Packer」（同）で展開する。

図3：IBM ConcertとLightwell、Ansibleで脆弱性管理を自動化する

　河野氏は「IBMはこうした仕組みを束ね、監査対応までを含めて脆弱性管理を一貫して担っていく」と力を込める。