特開 2023-87980 脆弱性管理システム、及び脆弱性管理方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023087980

(43)【公開日】2023-06-26

(54)【発明の名称】脆弱性管理システム、及び脆弱性管理方法

(51)【国際特許分類】

   G06F 21/57 20130101AFI20230619BHJP

【ＦＩ】

G06F21/57 370

【審査請求】有

【請求項の数】6

【出願形態】ＯＬ

(21)【出願番号】P 2021202570

(22)【出願日】2021-12-14

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110000176

【氏名又は名称】弁理士法人一色国際特許事務所

(72)【発明者】

【氏名】高橋 孝文

(57)【要約】      （修正有）

【課題】アプリケーション実行基盤（実行基盤）の複数のコンテナに脆弱性が存在する場合に、脆弱性を効率良く解消させる脆弱性管理システム及び方法を提供する。
【解決手段】アプリケーション管理システム１は、重み付け判定サーバとスケジューリングサーバを備える。重み付け判定サーバは、実行基盤内のコンテナ１１の脆弱性が実行基盤に与える影響の大きさを示す影響度係数を、脆弱性とその評価値とを対応づけた脆弱性情報に基づき算出する。また、コンテナのデータのアクセス頻度情報に基づき、コンテナが行う通信の形態に由来する脆弱性の評価値であるアクセス頻度係数を算出する。更に、影響度係数及びアクセス頻度係数に基づき、コンテナの脆弱性に対する対策の優先度を示す重み付け判定値を算出する。スケジューリングサーバは、各コンテナの重み付け判定値に基づき、各コンテナへの対策の順序を決定し、その順序に従って各コンテナへの対策を実行する。
【選択図】図１

【特許請求の範囲】

【請求項1】

プロセッサ及びメモリを有し、
１又は複数のコンテナによりアプリケーションが実行されるアプリケーション実行システムにおけるコンテナが有する脆弱性が前記アプリケーション実行システムに与える影響の大きさを示すパラメータである影響度係数を、脆弱性と当該脆弱性の評価値とを対応づけた情報である脆弱性情報に基づき算出する影響度係数算出部と、
前記コンテナが送信又は受信するデータの送信範囲又は受信範囲及び送信頻度又は受信頻度に関する情報であるアクセス頻度情報に基づき、前記コンテナが行う通信の形態に由来する脆弱性の評価値であるアクセス頻度係数を算出するアクセス頻度係数算出部と、
算出した前記影響度係数及び前記アクセス頻度係数に基づき、前記コンテナが有する脆弱性に対する対策の優先度を示す重み付け判定値を算出する重み付け判定値算出部と、
複数のコンテナについて算出した前記重み付け判定値に基づき、前記複数のコンテナのそれぞれに対する対策の順序を決定し、決定した順序に従って前記複数のコンテナのそれぞれに対する対策を実行するスケジューリング処理部と
を備える脆弱性管理システム。

【請求項2】

前記スケジューリング処理部は、前記複数のコンテナのそれぞれのデータアクセス頻度に基づき、当該コンテナが実行する処理の優先度を算出し、算出した前記処理の優先度が所定の閾値以下であるか否かを判定し、前記算出した処理の優先度が前記所定の閾値以下であると判定した場合に、当該処理の優先度に係るコンテナのプロセスを縮退させ、縮退させた後に、前記決定した対策の順序に従って前記複数のコンテナのそれぞれに対する対策を実行する、
請求項１に記載の脆弱性管理システム。

【請求項3】

前記アクセス頻度係数算出部は、前記コンテナのデータ送信及びデータ受信に優先順位を設定すると共に、前記コンテナが送信又は受信するデータの範囲が同一アプリケーション内であるか、他のアプリケーションであるか、又は他のアプリケーション実行システムであるかに従って優先順位を設定することにより、前記アクセス頻度係数を算出する、
請求項１に記載の脆弱性管理システム。

【請求項4】

情報処理装置が、
１又は複数のコンテナによりアプリケーションが実行されるアプリケーション実行システムにおけるコンテナが有する脆弱性が前記アプリケーション実行システムに与える影響の大きさを示すパラメータである影響度係数を、脆弱性と当該脆弱性の評価値とを対応づけた情報である脆弱性情報に基づき算出する影響度係数算出処理と、
前記コンテナが送信又は受信するデータの送信範囲又は受信範囲及び送信頻度又は受信頻度に関する情報であるアクセス頻度情報に基づき、前記コンテナが行う通信の形態に由来する脆弱性の評価値であるアクセス頻度係数を算出するアクセス頻度係数算出処理と、
算出した前記影響度係数及び前記アクセス頻度係数に基づき、前記コンテナが有する脆弱性に対する対策の優先度を示す重み付け判定値を算出する重み付け判定値算出処理と、
複数のコンテナについて算出した前記重み付け判定値に基づき、前記複数のコンテナのそれぞれに対する対策の順序を決定し、決定した順序に従って前記複数のコンテナのそれぞれに対する対策を実行するスケジューリング処理と
を実行する脆弱性管理方法。

【請求項5】

前記情報処理装置が、
前記スケジューリング処理において、前記複数のコンテナのそれぞれのデータアクセス頻度に基づき、当該コンテナが実行する処理の優先度を算出し、算出した前記処理の優先度が所定の閾値以下であるか否かを判定し、前記算出した処理の優先度が前記所定の閾値
以下であると判定した場合に、当該処理の優先度に係るコンテナのプロセスを縮退させ、縮退させた後に、前記決定した対策の順序に従って前記複数のコンテナのそれぞれに対する対策を実行する、
請求項４に記載の脆弱性管理方法。

【請求項6】

前記情報処理装置が、
前記アクセス頻度係数算出処理において、前記コンテナのデータ送信及びデータ受信に優先順位を設定すると共に、前記コンテナが送信又は受信するデータの範囲が同一アプリケーション内であるか、他のアプリケーションであるか、又は他のアプリケーション実行システムであるかに従って優先順位を設定することにより、前記アクセス頻度係数を算出する、
請求項４に記載の脆弱性管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、脆弱性管理システム、及び脆弱性管理方法に関する。

【背景技術】

【0002】

コンテナ技術を使用したアプリケーション実行基盤（例えば、kubernetes）が広く利用されており、アプリケーション実行基盤では複数のアプリケーションが連携して動作する。さらに近年では、セキュリティ対策に対する関心の高まりにより、アプリケーション実行基盤に既存の継続的インテグレーション/継続的デリバリー（ＣＩ／ＣＤ：Continuous Integration／Continuous Delivery）を組み込むことで、サービスを安定稼働させながらコンテナのセキュリティアップデートさせる運用を行う試みがなされている（いわゆるDevSecOps）。

【0003】

コンテナのアップデートに関する技術としては、例えば特許文献１に、検証装置のバッチジョブ解析部が、本番サーバに配備されたバッチジョブの実行前に、バッチジョブを解析し、利用するコンテナイメージを特定し、コンテナイメージ情報収集部は、コンテナイメージレジストリを参照して、コンテナイメージのバージョン情報を収集し、コンテナイメージ検証管理部は、バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされている場合に、バッチジョブを検証用サーバで実行し、監視検証部は、検証用サーバで実行されるバッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方を行うといった構成が開示されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１９－５６９８６号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、このようなアプリケーション実行基盤では、複数のコンテナに脆弱性が発見されそれらにセキュリティアップデートを行う必要があるにも関わらず、アプリケーション実行基盤のリソースに余裕がない場合がある。この場合、セキュリティ管理者は、各コンテナのアップデートのスケジュール調整を行わなければならず、各コンテナのアップデートの開始に待ち時間が生じる。これにより、脆弱性に対する対策が遅れて、セキュリティインシデントが起きるおそれがある。

【0006】

本発明は、このような背景に鑑みてなされたものであり、その目的は、アプリケーション実行システムの複数のコンテナに脆弱性が存在する場合に、それらの脆弱性を効率良く解消させることが可能な脆弱性管理システム、及び脆弱性管理方法を提供することを目的とする。

【課題を解決するための手段】

【0007】

上記課題を解決するための本発明の一つは、プロセッサ及びメモリを有し、１又は複数のコンテナによりアプリケーションが実行されるアプリケーション実行システムにおけるコンテナが有する脆弱性が前記アプリケーション実行システムに与える影響の大きさを示すパラメータである影響度係数を、脆弱性と当該脆弱性の評価値とを対応づけた情報である脆弱性情報に基づき算出する影響度係数算出部と、前記コンテナが送信又は受信するデータの送信範囲又は受信範囲及び送信頻度又は受信頻度に関する情報であるアクセス頻度情報に基づき、前記コンテナが行う通信の形態に由来する脆弱性の評価値であるアクセス
頻度係数を算出するアクセス頻度係数算出部と、算出した前記影響度係数及び前記アクセス頻度係数に基づき、前記コンテナが有する脆弱性に対する対策の優先度を示す重み付け判定値を算出する重み付け判定値算出部と、複数のコンテナについて算出した前記重み付け判定値に基づき、前記複数のコンテナのそれぞれに対する対策の順序を決定し、決定した順序に従って前記複数のコンテナのそれぞれに対する対策を実行するスケジューリング処理部とを備える脆弱性管理システム、とする。

【0008】

また、上記課題を解決するための本発明の一つは、情報処理装置が、１又は複数のコンテナによりアプリケーションが実行されるアプリケーション実行システムにおけるコンテナが有する脆弱性が前記アプリケーション実行システムに与える影響の大きさを示すパラメータである影響度係数を、脆弱性と当該脆弱性の評価値とを対応づけた情報である脆弱性情報に基づき算出する影響度係数算出処理と、前記コンテナが送信又は受信するデータの送信範囲又は受信範囲及び送信頻度又は受信頻度に関する情報であるアクセス頻度情報に基づき、前記コンテナが行う通信の形態に由来する脆弱性の評価値であるアクセス頻度係数を算出するアクセス頻度係数算出処理と、算出した前記影響度係数及び前記アクセス頻度係数に基づき、前記コンテナが有する脆弱性に対する対策の優先度を示す重み付け判定値を算出する重み付け判定値算出処理と、複数のコンテナについて算出した前記重み付け判定値に基づき、前記複数のコンテナのそれぞれに対する対策の順序を決定し、決定した順序に従って前記複数のコンテナのそれぞれに対する対策を実行するスケジューリング処理とを実行する脆弱性管理方法、とする。

【発明の効果】

【0009】

本発明によれば、アプリケーション実行システムの複数のコンテナに脆弱性が存在する場合に、それらの脆弱性を効率良く解消させることができる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

【図面の簡単な説明】

【0010】

【図1】本実施形態に係るアプリケーション管理システムの構成の一例を示す図である。

【図2】重み付け判定サーバが備える機能の一例を説明する図である。

【図3】スケジューリングサーバが備える機能の一例を説明する図である。

【図4】アプリケーション管理システムの各情報処理装置が備えるハードウェアの一例を示す図である。

【図5】アプリケーション管理システムが行う処理の概要を説明するフローチャートである。

【図6】重み付け判定値決定処理の一例を説明するフロー図である。

【図7】脆弱性情報管理ＤＢの一例を示す図である。

【図8】トラフィック管理ＤＢの一例を示す図である。

【図9】カテゴリ別リスク影響度係数ＤＢの一例を示す図である。

【図10】影響度係数ＤＢの一例を示す図である。

【図11】アクセス頻度管理ＤＢの一例を示す図である。

【図12】アクセス頻度係数管理ＤＢの一例を示す図である。

【図13】深刻度管理ＤＢの一例を示す図である。

【図14】重み付け判定ＤＢの一例を示す図である。

【図15】プロセス優先度係数決定処理の一例を説明するフロー図である。

【図16】アクセス記録ＤＢの一例を示す図である。

【図17】優先度記録ＤＢの一例を示す図である。

【図18】スケジューリング処理の一例を説明するフロー図である。

【図19】縮退を実行させるためのＡＰＩコマンドの一例を示す図である。

【図20】ＤＣＲの一例を示す図である。

【発明を実施するための形態】

【0011】

以下、本発明の一実施形態について説明する。
図１は、本実施形態に係るアプリケーション管理システム１の構成の一例を示す図である。アプリケーション管理システム１は、アプリケーション実行基盤１０、アプリケーション監視システム２０、ＣＤサーバ３０、脆弱性管理システム４０、ＣＩシステム５０、ホスト装置６０、及び脆弱性情報提供システム７０の各情報処理装置を含んで構成される。

【0012】

アプリケーション実行基盤１０は、各種のアプリケーションがコンテナ技術によって実行されるアプリケーション実行システムである。すなわち、アプリケーション実行基盤１０は、１又は複数のコンテナ１１で構成される、１又は複数のアプリケーション１２と、各アプリケーション１２の負荷を分散させるためのロードバランサ１３とを含む各プログラムを備える。また、アプリケーション実行基盤１０は、これらのアプリケーション（プログラム）を実行するためのオペレーティングシステム１４（ＯＳ：Operating System）を記憶している。アプリケーション実行基盤１０は、例えば、Kubernetesである。なお、ここでコンテナとは、アプリケーション（プログラム）の実行環境を記憶したデータ一般を指す。

【0013】

アプリケーション監視システム２０は、アプリケーション実行基盤１０におけるアプリケーション１２及びコンテナ１１の状態を監視する。アプリケーション監視システム２０は、トラフィック管理サーバ２１、統計管理サーバ２２、及びアクセス記録管理サーバ２３を備える。

【0014】

トラフィック管理サーバ２１は、各アプリケーション１２及びコンテナ１１が行う通信（データの送受信）の内容、例えばアプリケーション１２内若しくはアプリケーション１２間で行われる通信、及びアプリケーション実行基盤１０以外の他のアプリケーション実行システムとの間で行われる通信を監視し、これらの通信の履歴の情報（以下、トラフィック情報という）を蓄積している。統計管理サーバ２２は、アプリケーション監視システム２０における各種の統計処理を行う。アクセス記録管理サーバ２３は、所定のタイミング（例えば、所定の時刻又は所定の時間間隔）で繰り返し、所定期間における各コンテナのアクセス数の合計（以下、単にコンテナアクセス数という）の履歴を蓄積している。

【0015】

ＣＤサーバ３０（ＣＤ：Continuous Delivery）は、ＣＩシステム５０により作成され
たリソースに基づきアプリケーション実行基盤１０にコンテナ１１（アプリケーション１２）をデプロイする。

【0016】

脆弱性管理システム４０は、アプリケーション１２（コンテナ１１）の脆弱性に対する管理を行う。脆弱性管理システム４０は、重み付け判定サーバ４１及びスケジューリングサーバ４２を備える。重み付け判定サーバ４１は、アプリケーション１２（コンテナ１１）にて発見された脆弱性に対する対策の優先順位を判断するためのパラメータである重み付け判定値を算出する。スケジューリングサーバ４２は、重み付け判定値に従って、各コンテナ１１への脆弱性解消の対策処理を行う。脆弱性管理システム４０の詳細は後述する。

【0017】

ＣＩシステム５０（ＣＩ：Continuous Integration）は、アプリケーション１２を構成するリソースを作成すると共に、ホスト装置６０の各コンテナ１１の脆弱性の監視が可能な情報処理システムである。ＣＩシステム５０は、ソースコードライブラリ管理サーバ５１及びＣＩサーバ５２を備える。ソースコードライブラリ管理サーバ５１は、コンテナのリソース（ソースコード、ライブラリ等）を記憶している。ＣＩサーバ５２は、ホスト装
置６０の各コンテナの脆弱性の有無を監視する。また、ＣＩサーバ５２は、ソースコードライブラリ管理サーバ５１からリソースを取得し、取得したリソースに基づき、コンテナのイメージを作成(ビルド）する。なお、ＣＩシステム５０によるコンテナのビルドは、
管理者がＣＩシステム５０を操作することによって行われてもよいし、自動的に行われてもよい。

【0018】

ホスト装置６０は、アプリケーション実行基盤１０におけるアプリケーション１２を利用するユーザが使用する装置である。ホスト装置６０は、アプリケーション実行基盤１０が提供するアプリケーションのコンテナ６１を記憶している。ホスト装置６０は、複数存在してもよい。

【0019】

脆弱性情報提供システム７０は、コンテナに関する様々な脆弱性の情報を蓄積し管理している。脆弱性情報提供システム７０は、脆弱性公開サーバ７１及び脆弱性管理サーバ７２を備える。脆弱性公開サーバ７１は、コンテナが有する脆弱性に関する情報（以下、脆弱性公開情報という）を記憶している。また、脆弱性管理サーバ７２は、脆弱性管理システム４０に脆弱性公開情報を送信することができる。なお、脆弱性公開サーバ７１は、アプリケーション管理システム１の外部の情報処理システムに脆弱性公開情報を提供するものであってもよい。

【0020】

以上のアプリケーション管理システム１における各情報処理装置の間は、例えば、インターネット、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、又は専用
線等の有線又は無線の通信ネットワークにより通信可能となっている。

【0021】

次に、脆弱性管理システム４０の詳細を説明する。
＜重み付け判定サーバ＞
図２は、重み付け判定サーバ４１が備える機能の一例を説明する図である。重み付け判定サーバ４１は、影響度係数算出部４１１、アクセス頻度係数算出部４１２、及び重み付け判定値算出部４１３を備える。

【0022】

影響度係数算出部４１１は、１又は複数のコンテナ１１によりアプリケーションを実行するアプリケーション実行基盤１０におけるコンテナ１１が有する脆弱性がアプリケーション実行基盤１０に与える影響の大きさを示すパラメータである影響度係数を、脆弱性と当該脆弱性の所定の評価値とを対応づけた情報である脆弱性情報（後述する脆弱性情報管理ＤＢ１００）に基づき算出する。影響度係数は、後述する影響度係数ＤＢ１３０に記録される。

【0023】

アクセス頻度係数算出部４１２は、コンテナ１１が送信又は受信するデータの送信範囲又は受信範囲及び送信頻度又は受信頻度に関する情報であるアクセス頻度情報（後述するアクセス頻度管理ＤＢ１４０に記録される）に基づき、コンテナ１１が行う通信の形態に由来する脆弱性の評価値であるアクセス頻度係数を算出する。アクセス頻度係数は、後述するアクセス頻度係数ＤＢ１６０に記録される。なお、アクセス頻度情報は、トラフィック管理サーバ２１のトラフィック情報により作成される。トラフィック情報は、後述するトラフィック管理ＤＢ１２０に記録される。

【0024】

重み付け判定値算出部４１３は、影響度係数及びアクセス頻度係数に基づき、コンテナ１１が有する脆弱性に対する対策の優先度を示す重み付け判定値を算出する。重み付け判定値は、後述する重み付け判定ＤＢ１５０に記録される。

【0025】

また、重み付け判定サーバ４１は、カテゴリ別リスク影響度係数ＤＢ１１０、及び深刻度管理ＤＢ１７０の各データベースを記憶している。

【0026】

カテゴリ別リスク影響度係数ＤＢ１１０は、影響度係数を算出するための重みパラメータ（以下、カテゴリ別リスク影響度係数という）を記憶している。深刻度管理ＤＢ１７０は、影響度係数をカテゴリ化した情報（以下、深刻度という）を記憶している。カテゴリ別リスク影響度係数ＤＢ１１０及び深刻度管理ＤＢ１７０の詳細は後述する。

【0027】

＜スケジューリングサーバ＞
図３は、スケジューリングサーバ４２が備える機能の一例を説明する図である。スケジューリングサーバ４２は、プロセス優先度係数決定部４２１、スケジューリング処理部４２２を備える。

【0028】

プロセス優先度係数決定部４２１は、アクセス記録管理サーバ２３のコンテナアクセス数に基づき、各コンテナ１１がアプリケーション実行基盤１０において行うプロセスの優先順位の情報であるプロセス優先度を決定する。

【0029】

スケジューリング処理部４２２は、複数のコンテナ１１について算出した重み付け判定値に基づき、複数のコンテナ１１のそれぞれに対する対策の順序を決定し、決定した順序に従って複数のコンテナ１１のそれぞれに対する対策を実行する

【0030】

また、スケジューリングサーバ４２は、アクセス記録ＤＢ２００、及び優先度記録ＤＢ２１０の各データベースを記憶する。

【0031】

アクセス記録ＤＢ２００は、アプリケーション実行基盤１０の各アプリケーション１２のコンテナ１１による各プロセスのアクセスの履歴を記憶する。また、優先度記録ＤＢ２１０は、各アプリケーション１２のコンテナ１１により実行されるプロセスの優先度を記憶する。アクセス記録ＤＢ２００及び優先度記録ＤＢ２１０の詳細は後述する。

【0032】

ここで、図４は、アプリケーション管理システム１の各情報処理装置が備えるハードウェアの一例を示す図である。各情報処理装置は、CPU(Central Processing Unit)、DSP(Digital Signal Processor)、GPU(Graphics Processing Unit)、FPGA(Field-Programmable Gate Array)等の処理装置９１（プロセッサ）と、ROM(Read Only Memory)、RAM(Random Access Memory)等の主記憶装置９２（メモリ）と、HDD(Hard Disk Drive)、SSD(Solid State Drive)などの補助記憶装置９３と、マウスやキーボード等で構成される入力装置９４
と、液晶ディスプレイまたは有機EL（Electro-Luminescence）ディスプレイ等で構成される出力装置９５と、ＮＩＣ（Network Interface Card）、無線通信モジュール、ＵＳＢ（Universal Serial Interface）モジュール、又はシリアル通信モジュール等で構成される通信装置９６とを備える。

【0033】

各情報処理装置の各機能は、処理装置９１が、主記憶装置９２又は補助記憶装置９３に格納されているプログラムを読み出して実行することにより実現される。また上記のプログラムは、例えば、記録媒体に記録して配布することができる。なお、各情報処理装置は、その全部または一部が、例えば、クラウドシステムによって提供される仮想サーバのように、仮想化技術やプロセス空間分離技術等を用いて提供される仮想的な情報処理資源を用いて実現されるものであってもよい。また、各情報処理装置によって提供される機能の全部または一部は、例えば、クラウドシステムがＡＰＩ（Application Programming Interface）等を介して提供するサービスによって実現してもよい。
次に、アプリケーション管理システム１が行う処理の概要を説明する。

【0034】

図５は、アプリケーション管理システム１が行う処理の概要を説明するフローチャートである。

【0035】

まず、脆弱性管理システム４０は、各コンテナ１１（アプリケーション１２）の脆弱性に関する重み付け判定値を決定する重み付け判定値決定処理ｓ１を随時実行する。また、脆弱性管理システム４０は、各コンテナ１１のプロセスのプロセス優先度係数を決定するプロセス優先度係数決定処理ｓ３を随時実行する。

【0036】

１又は複数のコンテナ１１に脆弱性が発見された場合、脆弱性管理システム４０は、スケジューリング処理ｓ５を実行する。すなわち、脆弱性管理システム４０は、重み付け判定値決定処理ｓ１で決定した重み付け判定値により脆弱性の解消の処理順序を決定し、必要に応じて重み付け判定値及びプロセス優先度係数決定処理ｓ３で決定されたプロセス優先度係数に基づき空きリソースを増加させた上で、各コンテナ１１の脆弱性への対策（セキュリティアップデート）を行う。
なお、以上に説明した処理は繰り返し実行される。
次に、これらの処理について説明する。

【0037】

＜重み付け判定値決定処理＞
図６は、重み付け判定値決定処理ｓ１の一例を説明するフロー図である。重み付け判定値決定処理ｓ１は、ユーザにより指定されたタイミング又は所定のタイミング（例えば、所定の時刻、所定の時間間隔）で実行される。
まず、重み付け判定サーバ４１は、脆弱性情報管理ＤＢ１００を作成する（ｓ１１）。

【0038】

具体的には、まず、重み付け判定サーバ４１は、脆弱性管理サーバ７２から、脆弱性公開情報を受信する。そして、重み付け判定サーバ４１は、受信した脆弱性公開情報を脆弱性情報管理ＤＢ１００に記憶する。

【0039】

脆弱性公開情報は、例えば、各脆弱性の評価値（本実施形態では、所定の共通脆弱性評価システム（ＣＶＳＳ：Common Vulnerability Scoring System）により算出された脆弱
性の評価値であるＣＶＳＳスコア（ＣＶＳＳ：Common Vulnerability Scoring System)であるものとする）と、その脆弱性がアプリケーション実行基盤１０に与える影響の大きさの指標であるホストカテゴリ別影響度（後述するようにホスト装置６０のカテゴリごとに異なる）と、その脆弱性に対する対処方法の情報とを含む。

【0040】

重み付け判定サーバ４１は、脆弱性管理サーバ７２から受信した脆弱性公開情報を所定の画面に表示しユーザから脆弱性情報管理ＤＢ１００に係るデータの入力を受け付けるようにしてもよいし、受信した脆弱性公開情報に基づき所定のアルゴリズムにより自動的に脆弱性情報管理ＤＢ１００を作成してもよい。

【0041】

（脆弱性情報管理ＤＢ）
ここで、図７は、脆弱性情報管理ＤＢ１００の一例を示す図である。脆弱性情報管理ＤＢ１００は、脆弱性公開情報に基づく作成される脆弱性情報を記憶している。すなわち、脆弱性情報管理ＤＢ１００は、脆弱性１０１、ＣＶＳＳスコア１０２、ホストカテゴリ別影響度１０３、及び対処方法１０４の各データ項目を有する。

【0042】

脆弱性１０１には、脆弱性の種類の情報が設定される。ＣＶＳＳスコア１０２には、その脆弱性のＣＶＳＳスコアの情報が設定される。ホストカテゴリ別影響度１０３には、その脆弱性のホストカテゴリ別影響度が設定される。対処方法１０４には、その脆弱性に対して行う対処方法（アップデートの方法）を特定する情報が設定される。

【0043】

ホストカテゴリ別影響度１０３には、１又は複数のホストカテゴリ別影響度が設定される。ホストカテゴリ影響別影響度は、脆弱性がアプリケーション実行基盤１０に与える影
響の大きさを段階的に表した情報である。また、このホストカテゴリ影響別影響度は、ホスト装置６０のカテゴリごとに設定される。カテゴリは、例えば、アプリケーション実行基盤１０以外のコンテナシステムとデータの送受信を行う「公開サーバ」、アプリケーション実行基盤１０内のアプリケーション又はコンテナのみとデータの送受信を行う「内部サーバ」である。

【0044】

次に、図６に示すように、重み付け判定サーバ４１は、トラフィック管理ＤＢ１２０を作成する（ｓ１３）。

【0045】

具体的には、重み付け判定サーバ４１は、アクセス記録管理サーバ２３から、アプリケーション実行基盤１０の各コンテナ１１に関する通信の履歴(トラフィック情報）を受信
し、受信したトラフィック情報に基づき、トラフィック管理ＤＢ１２０を作成する。

【0046】

（トラフィック管理ＤＢ）
ここで、図８は、トラフィック管理ＤＢ１２０の一例を示す図である。トラフィック管理ＤＢ１２０は、アプリケーション１２１、インバウンド通信１２２、及びアウトバウンド通信１２３の各データ項目を有する。

【0047】

アプリケーション１２１には、各アプリケーションの各コンテナを特定する情報が設定される。

【0048】

インバウンド通信１２２には、アプリケーション１２１が示すコンテナが社外（アプリケーション実行基盤１０以外のコンテナシステム）からのデータを受信するインバウンド通信を行っている場合に、各種情報が設定される。すなわち、インバウンド通信１２２は、社外１２２１、社内１２２２、クラスター１２２３、及びローカル１２２４の各小データ項目を有する。社外１２２１には、アプリケーション１２１が示すコンテナがインバウンド通信として、社外からのデータを受信する社外通信を行っている場合には「○」が設定される。社内１２２２には、アプリケーション１２１が示すコンテナがインバウンド通信として、社内（アプリケーション実行基盤１０内）の他アプリケーションからのデータを受信する社内通信を行っている場合には「○」が設定される。クラスター１２２３には、アプリケーション１２１が示すコンテナがインバウンド通信として、社内の他のアプリケーションからのデータを受信するクラスター内通信を行っている場合には「○」が設定される。ローカル１２２４には、アプリケーション１２１が示すコンテナがインバウンド通信として、同一アプリケーションからのデータを受信するローカル通信を行っている場合には「○」が設定される。

【0049】

アウトバウンド通信１２３には、アプリケーション１２１が示すコンテナがアウトバウンド通信を行っている場合に、各種情報が設定される。すなわち、アウトバウンド通信１２３は、社外１２３１、社内１２３２、クラスター１２３３、及びローカル１２３４の各小データ項目を有する。社外１２３１には、アプリケーション１２１が示すコンテナがアウトバウンド通信として、社外通信を行っている場合には「○」が設定される。社内１２３２には、アプリケーション１２１が示すコンテナがアウトバウンド通信として、社内通信を行っている場合には「○」が設定される。クラスター１２３３には、アプリケーション１２１が示すコンテナがアウトバウンド通信として、クラスター内通信を行っている場合には「○」が設定される。ローカル１２３４には、アプリケーション１２１が示すコンテナがアウトバウンド通信として、ローカル通信を行っている場合には「○」が設定される。

【0050】

次に、図６に示すように、重み付け判定サーバ４１は、ｓ１３で作成したトラフィック管理ＤＢ１２０、及びｓ１１で作成した脆弱性情報管理ＤＢ１００に基づき、各コンテナ
の影響度係数を算出する（ｓ１５）。

【0051】

具体的には、重み付け判定サーバ４１は、トラフィック管理ＤＢ１２０に基づき、各コンテナが行っている通信の形態を特定することで、ホスト装置６０のカテゴリを特定する。そして、重み付け判定サーバ４１は、脆弱性情報管理ＤＢ１００及び後述するカテゴリ別リスク影響度係数ＤＢ１１０に基づき、ホストカテゴリ別影響度係数を特定する。重み付け判定サーバ４１は、脆弱性情報管理ＤＢ１００を参照することで、各コンテナの各脆弱性のＣＶＳＳスコアと、前記で算出した各コンテナのカテゴリ別リスク影響度係数とを乗算することにより、各コンテナの影響度係数を算出する（ｓ１７）。重み付け判定サーバ４１は、算出した影響度係数の情報を影響度係数ＤＢ１３０に設定する。

【0052】

例えば、重み付け判定サーバ４１は、トラフィック管理ＤＢ１２０を参照し、あるコンテナに係る各レコードのインバウンド通信１２２の社外１２２１及びアウトバウンド通信１２３の社外１２３１の各データを参照し、そのコンテナは社外通信を行っていることを特定する。そして、重み付け判定サーバ４１は、脆弱性情報管理ＤＢ１００のある脆弱性Ａに係るレコードのホストカテゴリ別影響度１０３の内容を取得することで、当該コンテナに係るホスト装置６０のカテゴリが社外通信を行う「公開サーバ」でありそのホストカテゴリ別影響度は「高」であることを特定する。重み付け判定サーバ４１は、カテゴリ別リスク影響度係数ＤＢ１１０（次述）を参照することで、ホストカテゴリ別影響度「高」に対応するホストカテゴリ別影響度係数は「１．５」であることを特定する。そして、重み付け判定サーバ４１は、上記脆弱性情報管理ＤＢ１００のレコードのＣＶＳＳスコア１０２からＣＶＳＳスコア「６．３」を取得する。重み付け判定サーバ４１は、カテゴリ別リスク影響度係数「１．５」と、ＣＶＳＳスコア「６．３」とを乗算することで、当該コンテナの脆弱性Ａに関する影響度係数を算出する。

【0053】

（カテゴリ別リスク影響度係数ＤＢ）
ここで、図９は、カテゴリ別リスク影響度係数ＤＢ１１０の一例を示す図である。カテゴリ別リスク影響度係数ＤＢ１１０は、番号１１１、リスク影響度１１２、及び係数１１３の各データ項目を有する。番号１１１には、各レコード番号が設定される。リスク影響度１１２には、ホストカテゴリ別影響度が設定される。係数１１３は、そのホストカテゴリ別影響度に対応するカテゴリ別リスク影響度係数の情報が設定される。

【0054】

（影響度係数ＤＢ）
図１０は、影響度係数ＤＢ１３０の一例を示す図である。影響度係数ＤＢ１３０は、アプリケーション１３１及び脆弱性１３２の各データ項目を有する。

【0055】

アプリケーション１３１には、各アプリケーションにおける各コンテナを特定する情報が設定される。脆弱性１３２は、合計１３２１及びカテゴリ１３２２の各小データ項目を有する。合計１３２１には、そのコンテナが有する全脆弱性の影響度係数の合計が設定される。カテゴリ１３２２には、そのコンテナの各脆弱性に関する影響度係数が設定される。

【0056】

次に、図６に示すように、重み付け判定サーバ４１は、アクセス頻度係数管理ＤＢ１６０を作成する（ｓ１７）。

【0057】

具体的には、まず、重み付け判定サーバ４１は、アクセス記録管理サーバ２３から、アプリケーション実行基盤１０の各コンテナ１１に関する通信の履歴(コンテナアクセス数
）を受信し、受信したコンテナアクセス数に基づき、アクセス頻度管理ＤＢ１４０を作成する。

【0058】

（アクセス頻度管理ＤＢ）
図１１は、アクセス頻度管理ＤＢ１４０の一例を示す図である。アクセス頻度管理ＤＢ１４０は、トラフィック管理ＤＢ１２０と同様の、アプリケーション１４１、インバウンド通信１４２、及びアウトバウンド通信１４３のデータ項目とこれらに対するデータ小項目とを有する。ただし、アクセス頻度管理ＤＢ１４０の各データ項目には、インバウンド通信又はアウトバウンド通信のアクセス頻度情報が設定される。例えば、各データ項目には、過去７日間に発生した通信の頻度の平均値が設定される。

【0059】

そして、重み付け判定サーバ４１は、作成したアクセス頻度管理ＤＢ１４０を参照することで、各コンテナが行う通信の形態を特定し、その形態の通信及びアクセス頻度情報に基づき、各コンテナのアクセス頻度係数を算出する。

【0060】

例えば、重み付け判定サーバ４１は、各コンテナを、インバウンド通信を行うコンテナのカテゴリとアウトバウンド通信を行うコンテナのカテゴリとに区分し、インバウンド通信を行うコンテナのアクセス頻度係数がアウトバウンド通信を行うコンテナのアクセス頻度係数より小さくなるように各アクセス頻度係数を設定する（順位を高くする）。また、重み付け判定サーバ４１は、各カテゴリにおけるコンテナをさらに、社外通信を行うコンテナのカテゴリと、社内通信を行うサブカテゴリと、クラスター内通信を行うカテゴリと、ローカル通信を行うサブカテゴリとに区分し、これらの順序でアクセス頻度係数を小さくする（順位を高くする）。重み付け判定サーバ４１は、各サブカテゴリにおいて、アクセス頻度が高い順に、アクセス頻度係数を小さくする（順位を高くする）。このように、１．「インバウンド通信＞アウトバンド通信」、２．「社外通信＞社内通信＞クラスター内通信＞ローカル通信」、３．アクセス頻度順、といった優先順位を設定する。

【0061】

（アクセス頻度係数管理ＤＢ）
図１２は、アクセス頻度係数管理ＤＢ１６０の一例を示す図である。アクセス頻度係数管理ＤＢ１６０は、アクセス頻度管理ＤＢ１４０と同様の、アプリケーション１６１、インバウンド通信１６２、及びアウトバウンド通信１６３のデータ項目とこれらに対するデータ小項目とを有する。アクセス頻度係数管理ＤＢ１６０の各データ項目には、アクセス頻度係数の情報が設定される。本実施形態では、アクセス頻度係数は、優先順位の数値として表され、その値が小さいほど脆弱性に対する対策を優先的に行うべきことを示すものとする。

【0062】

次に、図６に示すように、重み付け判定サーバ４１は、各コンテナについて、ｓ１５で算出した影響度係数とｓ１７で算出したアクセス頻度係数とに基づき、各コンテナの重み付け判定値を算出する（ｓ１９）。重み付け判定サーバ４１は、各コンテナの重み付け判定値の情報を、重み付け判定ＤＢ１５０に記録する。

【0063】

具体的には、まず、重み付け判定サーバ４１は、各コンテナについて、深刻度管理ＤＢ１７０を参照することにより、ｓ１５で算出した影響度係数（各コンテナの全脆弱性に関する影響度係数）に対応する深刻度のカテゴリを特定する。そして、重み付け判定サーバ４１は、各コンテナを深刻度ごとに区分し、深刻度がより高いコンテナの重み付け判定値がより小さくなるように（優先順位が高くなるように）設定する。

【0064】

そして、重み付け判定サーバ４１は、アクセス頻度係数ＤＢ１６０を参照し、各深刻度のコンテナにおいて、アクセス頻度係数がより小さい（優先順位が高い）カテゴリの重み付け判定値がより小さくなるように（優先順位が高くなるように）設定する。

【0065】

（深刻度管理ＤＢ）
ここで、図１３は、深刻度管理ＤＢ１７０の一例を示す図である。深刻度管理ＤＢ１７
０は、深刻度１７１及びスコア１７２の各データ項目を有する。深刻度１７１には、深刻度のカテゴリの情報が設定される。スコア１７２には、深刻度１７１に対応する影響度係数の範囲の情報が設定される。なお、本実施形態では、深刻度１７１には、深刻度が高い（脆弱性に対する対策の優先度が高い）順に、「緊急」、「重要」、「警告」、「注意」、「なし」のいずれかが設定されているものとする。

【0066】

（重み付け判定ＤＢ）
図１４は、重み付け判定ＤＢ１５０の一例を示す図である。重み付け判定ＤＢ１５０は、アプリケーション１５１、重み付け判定値１５２、及びカテゴリ１５３の各データ項目を有する。

【0067】

アプリケーション１５１には、各アプリケーションにおける各コンテナを特定する情報が設定される。重み付け判定値１５２には、そのコンテナの重み付け判定値が設定される。カテゴリ１５３には、そのコンテナの深刻度のカテゴリの情報が設定される。本実施形態では、各コンテナの重み付け判定値は、深刻度が高いカテゴリほど小さい値（優先度が高い）であって、かつ各カテゴリにおいてはアクセス頻度係数が大きいコンテナほど小さい値が設定される。重み付け判定値は、複数のコンテナに脆弱性が存在している場合に、その解消の処理順序として反映される。
次に、スケジューリングサーバが行う処理について説明する。

【0068】

＜プロセス優先度係数決定処理＞
図１５は、プロセス優先度係数決定処理ｓ３の一例を説明するフロー図である。プロセス優先度係数決定処理ｓ３は、ユーザにより指定されたタイミング又は所定のタイミング（例えば、所定の時刻、所定の時間間隔）で実行される。

【0069】

スケジューリングサーバ４２のプロセス優先度係数決定部４２１は、アクセス記録管理サーバ２３が記憶しているコンテナアクセス数の情報を取得し、取得した情報に基づきアクセス記録ＤＢ２００を作成又は更新する（ｓ３１）。

【0070】

（アクセス記録ＤＢ）
図１６は、アクセス記録ＤＢ２００の一例を示す図である。アクセス記録ＤＢ２００は、レコード番号２０１、プロセス２０２、及びアクセス数２０３の各データ項目を有する１又は複数のレコードからなる。

【0071】

レコード番号２０１には、レコードの番号が設定される。プロセス２０２には、各コンテナのプロセスを特定する情報が設定される。アクセス数２０３には、そのプロセスに係るアクセス数の履歴が設定される。具体的には、アクセス記録管理サーバ２３が各タイミングで記録したコンテナアクセス数のうち、過去直近所定回数分のコンテナアクセス数が設定される。

【0072】

そして、図１５に示すように、プロセス優先度係数決定部４２１は、ｓ３１で作成又は更新したアクセス記録サーバ２００に基づき、優先度記録ＤＢ２１０を作成又は更新する（ｓ３３）。以上でプロセス優先度係数決定処理ｓ３は終了する。

【0073】

具体的には、プロセス優先度係数決定部４２１は、統計的に現時点又は直近の将来でアクセス数が大きいコンテナのプロセスのプロセス優先度係数を高くし、統計的に現時点又は直近の将来でアクセス数が少ないコンテナのプロセスのプロセス優先度係数を低くすることで、優先度記録ＤＢ２１０を作成又は更新する。

【0074】

例えば、プロセス優先度係数決定部４２１は、アクセス記録管理サーバ２３に記録され
ている直近所定回数分のアクセス記録のそれぞれの回について、アクセス数が最大であったプロセス及びアクセス数が最小であったプロセスを特定することで、上記アクセス記録においてアクセス数が最大であった回数が最も多かったプロセス（以下、最大頻度プロセスという）と、過去所定回分においてアクセス数が最小であった回数が最も多かったプロセス（以下、最小頻度プロセスという）とを特定する。プロセス優先度係数決定部４２１は、特定した最大頻度プロセスのプロセス優先度係数と、前回の同処理で特定したの最大頻度プロセスのプロセス優先度係数とを交換する。また、プロセス優先度係数決定部４２１は、特定した最小頻度プロセスのプロセス優先度係数と、前回の最小頻度プロセスのプロセス優先度係数とを交換する。

【0075】

（優先度記録ＤＢ）
図１７は、優先度記録ＤＢ２１０の一例を示す図である。優先度記録ＤＢ２１０は、レコード番号２１１、プロセス２１２、及び優先度２１３の各データ項目を有する。レコード番号２１１には、レコードの番号の情報が設定される。プロセス２１２には、各コンテナの各プロセスを特定する情報が設定される。優先度２１３には、そのプロセスのプロセス優先度係数の履歴の情報が設定される。

【0076】

＜スケジューリング処理＞
次に、図１８は、スケジューリング処理ｓ５の一例を説明するフロー図である。スケジューリング処理ｓ５は、例えば、アプリケーションの１又は複数のコンテナに脆弱性が検出された場合に実行される。なお、ここで、スケジューリングサーバ４２は、重み付け判定値処理ｓ１で作成した重み付け判定ＤＢ１５０を参照することで、脆弱性を解消すべきコンテナの優先度（処理順序）を特定しているものとする。

【0077】

スケジューリングサーバ４２のスケジューリング処理部４２２は、アプリケーション実行基盤１０の現在の空きリソースに、コンテナ（アプリケーション）の脆弱性を解消する処理をするための充分な余裕があるか否かを判定する（ｓ５１）。例えば、スケジューリング処理部４２２は、現在のアプリケーション実行基盤１０のリソースの情報を取得し、そのリソースが所定の閾値を超えているか否かを判定する。なお、この閾値は、常に一定の値としてもよいし、アプリケーション実行基盤１０で現在稼動しているリソース又は脆弱性があるコンテナの数等の各種要素に応じて異なる値としてもよい。

【0078】

空きリソースに充分な余裕がある場合は（ｓ５１：ＹＥＳ）、スケジューリング処理部４２２はｓ５３の処理を実行し、空きリソースに充分な余裕がない場合は（ｓ５１：ＮＯ）、スケジューリング処理部４２２はｓ５７の処理を実行する。

【0079】

ｓ５７においてスケジューリング処理部４２２は、優先度記録ＤＢ２１０から、各コンテナの各プロセスのプロセス優先度係数を取得する。

【0080】

そして、スケジューリング処理部４２２は、ｓ５７で取得したプロセス優先度係数に基づき、各プロセスについて、そのプロセスを縮退させる（冗長化数を削減する）か否かを判定する（ｓ５９）。具体的には、スケジューリング処理部４２２は、ｓ５７で取得したプロセス優先度係数が所定の閾値（例えば、３０）以下であるか否かを、各プロセスについて判定する。

【0081】

縮退させる（冗長化数を削減する）プロセスがある場合は（ｓ５９：ＹＥＳ）、スケジューリング処理部４２２はそのプロセスについて、ｓ６１の処理を実行し、縮退させる（冗長化数を削減する）プロセスがない場合は（ｓ５９：ＮＯ）、スケジューリング処理部４２２はｓ５１の処理を繰り返す。

【0082】

ｓ６１においてスケジューリング処理部４２２は、縮退を実現させるべく、プロセスの冗長化数を削減する。なお、図１９に、アプリケーション実行基盤１０に縮退を実行させるためのＡＰＩ（Application Programming Interface）コマンドの一例を示す。これに
より、アプリケーション実行基盤１０におけるリソースの空きが増加する。なお、スケジューリング処理部４２２は、その後脆弱性の解消が終了した場合に、縮退させたプロセスの冗長化数を元に戻してもよい。

【0083】

そして、スケジューリング処理部４２２は、プロセスを縮退させたコンテナの構成をアプリケーション実行基盤１０に反映させる（ｓ６３）。例えば、ＣＤサーバ３０は、スケジューリング処理部４２２からの指示に基づき、アプリケーション実行基盤１０へのコンテナのデプロイ、デプロイされたコンテナに係るアプリケーションの試験実行、及び、試験実行に成功したアプリケーションの、元のアプリケーションとの入れ替えの各処理を実行する。コンテナのデプロイ、試験実行、及び入れ換えの各処理の手順は、次述するｓ５３の処理において説明する。その後は、ｓ５１の処理が繰り返される。

【0084】

一方、ｓ５３においてスケジューリング処理部４２２は、以下に説明するように、脆弱性を有するアプリケーションのコンテナについて、デプロイ、試験実行、及び入れ替えの各処理を実行する。

【0085】

すなわち、まず、スケジューリング処理部４２２は、アプリケーションのコンテナが有する脆弱性を解消するためのアップデート処理の内容（対処方法）を、脆弱性情報管理ＤＢ１００から取得する。

【0086】

そして、スケジューリング処理部４２２は、その対処方法の実現に必要なリソースを取得をＣＩサーバ５２に指示する。ＣＩサーバ５２は、ソースコードライブラリ管理サーバ５１からリソースを取得し、取得したリソースに基づきコンテナのイメージをビルドする（作成する）。なお、この処理は、スケジューリング処理ｓ５の実行前に（例えば脆弱性が検出されたときに）、予め実行されていてもよい。

【0087】

ＣＤサーバ３０は、ビルドされたコンテナのイメージをアプリケーション実行基盤１０にデプロイする。例えば、ＣＤサーバ３０は、アップデートするＯＳ上で動作しているアプリケーション（例えば、Pod）を一時的に他のＯＳに移動させた上で、ＯＳのアップデ
ートを実行する。これにより、アプリケーション実行基盤１０のサービスを停止せずにアップデートを実行することができる。

【0088】

このデプロイの完了後、ＣＤサーバ３０は、所定時間、アプリケーション実行基盤１０の各アプリケーションを試験実行する。ＣＤサーバ３０は、試験実行後、この試験実行が成功したと判定した場合には、アプリケーション実行基盤１０にデプロイしたコンテナのイメージと、これまで存在していたコンテナのイメージとを入れ替える。

【0089】

その後、スケジューリング処理部４２２は、次に脆弱性を解消すべき（次の優先順位の）コンテナのイメージがあるか否かを判定する（ｓ５５）。次に脆弱性を解消すべきコンテナのイメージがある場合は（ｓ５５：ＹＥＳ）、スケジューリング処理部４２２はｓ５１の処理を繰り返し、次に脆弱性を解消すべきコンテナのイメージがない場合は（ｓ５５：ＮＯ）、スケジューリング処理ｓ５は終了する（ｓ６５）。

【0090】

なお、アプリケーション実行基盤１０のコンテナ１１のアップデート、デプロイ、及びリリースの方法は特に限定されないが、本実施形態では、ＣＤサーバ３０は、ＤＣＲ（Dark Canary Release）及びＰＤ（Progressive Delivery）に基づき、試験実行及びデプロ
イを実行するものとする。ＤＣＲは、所定の開発者のみに対してアップデート及びリリー
スを行う手法である。これにより、アプリケーション実行基盤１０に対する影響を与えず確実かつ安全にリリースを行うことができる。ＰＤは、継続的デリバリ（ＣＤ：Continuous Deliverty）の次のステップとして、全てのユーザにリリースする前に、所定の分析（正解率及びパフォーマンスの検証等）を行いその結果（一部のユーザによる検証の結果）に応じて自動ロールバックを行うデプロイの方法である。なお、図２０に、ＤＣＲの一例を示す。なお、アップデート及びリリースの方法は、他の手法、例えばＡ／Ｂテスト又はＣＲ（Canary Release）であってもよい。

【0091】

以上に説明したように、本実施形態の脆弱性管理システム４０は、アプリケーション実行基盤１０におけるコンテナ１１が有する脆弱性がアプリケーション実行基盤１０に与える影響の大きさを示す影響度係数を脆弱性情報に基づき算出し、各コンテナのアクセス頻度情報に基づきアクセス頻度係数を算出し、影響度係数及びアクセス頻度係数に基づき、コンテナが有する脆弱性に対する対策の優先度を示す重み付け判定値を算出し、複数のコンテナについて算出した重み付け判定値に基づき、複数のコンテナのそれぞれに対する対策の順序を決定し、決定した順序に従って複数のコンテナのそれぞれに対する対策を実行する。

【0092】

すなわち、本実施形態の脆弱性管理システム４０は、各コンテナ（アプリケーション）の脆弱性の解消の優先度を、システムに与える影響及びプロセスの優先度の観点から決定し（重み付け判定値）、その重み付け判定値による順序に従って各コンテナの脆弱性を解消する。

【0093】

このように、本実施形態の脆弱性管理システム４０によれば、複数の脆弱性がアプリケーション実行システムに存在する場合に、それらの脆弱性を効率良く解消させることができる。

【0094】

また、本実施形態の脆弱性管理システム４０は、各コンテナのデータアクセス頻度に基づき各コンテナのプロセス優先度を算出し、算出したプロセス優先度が所定の閾値以下である場合に、そのプロセス優先度に係るコンテナのプロセスを縮退させ、縮退させた後に、重み付け判定値により上記で決定した順序に従って各コンテナに対する対策を実行する。

【0095】

このように、優先度が低いプロセスを縮退させる（冗長化数を減少させる）ことでアプリケーション実行基盤１０の空きリソースを増加させることで、各コンテナの脆弱性解消の処理を迅速に行うことができるようになる。

【0096】

また、本実施形態の脆弱性管理システム４０は、コンテナのデータ送信及びデータ受信に優先順位を設定すると共に（インバウンド通信とアウトバウンド通信の優先順位）、コンテナが送信又は受信するデータの範囲が同一アプリケーション内であるか（ローカル通信）、アプリケーション実行基盤１０の他のアプリケーションであるか（クラスター内通信）、又は他のアプリケーション実行システム（社外通信）であるかに従って優先順位を設定することにより、アクセス頻度係数を算出する。

【0097】

このように、アプリケーション実行基盤１０及びアプリケーションにおける通信の形態に基づいてアクセス頻度係数を算出することで、データ通信のリスクの大小に従った脆弱性対策の優先順位を決定することができる。

【0098】

本発明は上記実施形態に限定されるものではなく、その要旨を逸脱しない範囲内で、任意の構成要素を用いて実施可能である。以上説明した実施形態や変形例はあくまで一例であり、発明の特徴が損なわれない限り、本発明はこれらの内容に限定されるものではない
。また、上記では種々の実施形態や変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

【0099】

また、本実施形態の各装置が備える各機能の一部は他の装置に設けてもよいし、別装置が備える機能を同一の装置に設けてもよい。

【0100】

また、本実施形態で説明した影響度係数やアクセス頻度係数の算出式は一例であり、任意の数式やパラメータを追加し又は変形してもよい。また、脆弱性の評価値は、ＣＶＳＳスコア以外の評価値であってもよい。

【符号の説明】

【0101】

１０ アプリケーション実行基盤
１１ コンテナ
４０ 脆弱性管理システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】