- Column
- AI技術を競争力に変える、実装から定着までの道筋
悪用までの猶予が「1分」に迫るフロンティアAI時代に開発と本番を貫く脆弱性管理が必要
「インプレス AI Days 2026」より、日本IBM ソフトウェア事業統括 オートメーション・プラットフォーム事業部の河野 哲也 氏
- 提供：
- 日本IBM
優先順位付けには、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」（同）で展開する。
河野氏は「IBMはこうした仕組みを束ね、監査対応までを含めて脆弱性管理を一貫して担っていく」と力を込める。
