1 イメージの脆弱性管理の概要
1.1 目的と期待される効果
イメージの脆弱性管理は、配布物としてのコンテナイメージや仮想マシンイメージに内在する欠陥を継続的に把握し、優先度を付けて是正し、再発防止までを組織的に回すことを目的とする。主な効果は、攻撃に悪用される可能性が高い部分から順に対処できる点、修正の根拠や期限を記録できる点、さらに運用のばらつきを抑えて管理品質を一定に保てる点にある。
また、静的な結果（スキャンで見つかった事実）に留まらず、実運用での露出状況や到達可能性を踏まえてリスクを再評価するため、「見つかったが影響が限定的」という誤認を減らせる。逆に、表面的には軽微に見えるものでも、設定やネットワーク構成次第で重要度が上がる場合に早期へ是正を寄せられる。
1.2 対象となる「イメージ」の範囲
ここでいうイメージとは、実行環境を構成するために配布・再利用されるパッケージ状の成果物である。管理対象は、単体で完結していなくてもよく、ベース部分と追加部分の双方を含めて追跡可能であることが望ましい。実務では、同じソフトウェアでも作り方や取り回しが異なると脆弱性の見え方が変わるため、識別と棚卸しの段階が重要になる。
1.2.1 コンテナイメージ
コンテナイメージは、層（レイヤ）を積み上げて形成され、配布単位として扱われることが多い。管理の焦点は、ベースとなるOS層、アプリ依存の追加層、ビルド時に持ち込まれたツール類の残り、実行時に使用する設定ファイルなどに分散しがちな点である。
さらに、ランタイム差分（例えば起動オプションやマウント、環境変数）によって脆弱性の実害性が変化しうる。したがって、イメージの内容そのものに加え、利用形態まで含めた評価に拡張する必要がある。
1.2.2 仮想マシンイメージ
仮想マシンイメージは、OSとアプリケーション、必要な設定を含むディスクのひな形として提供される場合がある。コンテナと比べて層の概念が明確でないことも多く、追跡はファイル単位やパッケージ単位の情報に依存しやすい。
加えて、ブート時設定、初期化スクリプト、ログ出力や管理ユーザの作り方など、運用に強く影響する要素が成果物に含まれやすい。そのため、スキャン結果だけでなく、展開・初期化プロセスの差分を評価の前提に組み込む設計が求められる。
1.3 管理対象の脆弱性の種類
管理対象には、アプリケーションの欠陥だけでなく、OSやミドルウェアに起因するもの、さらに部品供給の過程で混入・混在したものも含まれる。分類の目的は、責任分界（誰が直すか）と、対処の難しさ（いつ、どう修正するか）を見通すことにある。
1.3.1 アプリケーション依存の脆弱性
アプリケーション依存の脆弱性は、プログラムコードやそれが依存するライブラリ、言語ランタイム、設定テンプレートに起因する欠陥を指す。典型例としては、パラメータの扱いの不備、権限制御の誤り、依存ライブラリの既知欠陥などがある。
対処は再ビルドや依存関係の更新が中心となるが、イメージ上のどの層に該当するかで作業範囲が変わる。したがって、部品表やビルド情報を通じて、依存の導入元と版本を追跡できる状態を維持することが重要になる。
1.3.2 OS・ミドルウェア由来の脆弱性
OS・ミドルウェア由来の脆弱性は、カーネルやユーザランドのパッケージ、ウェブサーバ、データベース、認証基盤、ランタイム周辺などに広がる。特に、パッチ適用が可能な範囲と、再起動・互換性確認が必要な範囲が異なるため、更新計画は技術要件と運用制約の両方を反映する必要がある。
また、同じOSでもディストリビューションやリポジトリ運用の差でパッチ提供のタイミングが変わる。結果として、修正までのリードタイムがリスクの一部となるため、期限管理と例外設計の精度が左右する。
1.3.3 サプライチェーン起因の脆弱性
サプライチェーン起因の脆弱性は、部品や成果物の取得過程、ビルド手順、署名・検証の体制などに関連して発生する。既知の脆弱性そのものだけでなく、意図しない改変や不適切な取得元により、想定外の依存が混入するケースもこの領域に含めて扱う。
実務では、供給元の信頼性、ビルド再現性、署名検証、部品表の整合性、更新履歴の追跡といった手当が重要になる。修正は「該当部品の更新」だけでなく、「再取得・再ビルド・置換」の一連の作業として定義し直す必要がある。
2 全体プロセス（ライフサイクル）
2.1 収集と前処理
2.1.1 対象イメージの識別と棚卸し
前処理の最初の仕事は、組織内で存在し、利用され、また配布されるイメージを識別して一覧化することにある。ここでの棚卸しは、単にファイルを列挙するのではなく、識別子（タグやダイジェスト）、作成経路（ビルドパイプライン）、利用先（環境やクラスタ、VM展開先）を結び付ける作業を含む。
適切な識別がないと、後段のスキャン結果が実環境のどこに反映されるか不明になり、修正の優先付けが歪む。特にタグは移動することがあるため、内容の同一性を保証する識別（ハッシュ等）で管理する方針を採ると、後の回帰確認が容易になる。
2.2 脆弱性の検出
2.2.1 スキャン手法（CVE照合、SBOM活用、設定検査）
検出は複数手法を組み合わせて行う。代表的には、既知脆弱性の識別子（CVE）との照合により、パッケージや依存ライブラリのバージョンから該当性を推定する方式がある。これに加えて、SBOMを活用して部品の構成とバージョンを厳密に結び付けることで、推定の誤差を抑える。
さらに、設定検査も欠かせない。脆弱性そのものが存在していても、機能が無効化されている、外部公開がない、認証が適切に設定されているなどで実害が変わるため、構成値や有効化状況を読み取る必要がある。
2.2.2 スキャン対象の粒度（ベース層、追加層、ランタイム差分）
スキャンの粒度は、イメージのどこを見ているかを明確にすることで決まる。コンテナでは、ベース層と追加層で構成が異なり、更新の影響範囲も変わるため、層ごとの評価が有用である。仮想マシンでは、パッケージ集合や重要ディレクトリなど、実装依存の単位で整理することが多い。
加えて、ランタイム差分（起動時の設定、マウント、ネットワーク越しの到達性、環境変数）によってリスクが増減する。そこで、検出フェーズの情報として「スキャンで確定した内容」と「運用情報で補う内容」を分け、後工程の評価で整合させる設計が望ましい。
2.3 評価と優先順位付け
2.3.1 影響度の算定（露出度、到達可能性、悪用可能性）
評価では、脆弱性の存在に加え、実際の影響の出方を見積もる。露出度は外部からのアクセス可否や公開範囲を示し、到達可能性はネットワーク経路や認可の前提を含む概念になる。悪用可能性は、必要条件（特定リクエスト、権限、ユーザ操作）や攻撃に利用される可能性を反映する。
これらを組み合わせて、同じCVEでも優先度が変わる状態を作る。特に、公開サービスを担当するイメージや管理系機能を持つ環境では、スキャン上の点数が低くても対応を急ぐことがある。
2.3.2 優先度ルール（締切、重要資産、攻撃経路）
優先順位は、計算結果だけでなくルールで制御する。締切は、ベンダのパッチ公開や既知の悪用事例の出現時点、運用停止の可否などを反映して決める。重要資産は、金銭・個人情報・認証基盤など、損害の大きさに基づいてランク付けする。
攻撃経路に関するルールも効果的である。例えば、インターネット経由の経路で利用されるコンポーネントは、内部専用のものより高い優先度とするなど、経路ごとの取り扱いを明文化する。これにより担当者が判断に迷いにくくなり、例外が発生しても監査可能な形で残せる。
2.4 修正と再配布
2.4.1 パッチ適用と再ビルド
修正は、原則として安全なバージョンへ更新する方針で進める。OSやミドルウェアならパッチ適用、アプリケーションなら依存更新やコード修正を行い、その後にイメージを再ビルドして置き換える。再ビルドの際は、更新対象が正しく取り込まれたことを検証し、不要な差分が増えないように管理する。
また、パッチ適用だけでなく、互換性確認や設定値の再調整が必要になる場合がある。これらを作業の一部として計画に含めると、デプロイ後の障害リスクを抑えられる。
2.4.2 イメージの更新戦略（ローリング、段階導入）
更新戦略は、利用者への影響を抑えつつ効果を早く得るための設計である。ローリング更新は段階的に置換して問題を早期に検知しやすい。段階導入は、重要度の高い環境から、あるいは検証用の環境から順に適用するなど、組織の運用スタイルに合わせて順序を決める。
戦略の選定では、可用性要件、テスト能力、復旧手順の成熟度を考慮する。リスクの高い欠陥ほど迅速な更新が必要になる一方、品質を担保するための検証時間も必要になるため、両者を両立する計画が求められる。
2.5 検証と継続監視
2.5.1 再スキャンと回帰確認
修正後は再スキャンで効果を確認し、可能であれば回帰テストで機能面の異常を調べる。再スキャンは「問題が解消したか」だけでなく、「意図した以外の脆弱性が増えていないか」を見る役割もある。特に依存更新を伴う場合、別の欠陥が新たに出ることがあるため、差分の把握が重要になる。
回帰確認は必須範囲を段階化し、リスクに応じて厚みを変える。例えば、認証関連の変更がある場合は重点的な動作確認が必要になる。
2.5.2 アラートとレポート運用
継続監視では、検出が「一度きりの作業」で終わらない仕組みが要点となる。新しい脆弱性情報が出た場合に自動で対象イメージへ再評価を行い、アラートとして通知する。通知は、担当者がすぐに行動できる粒度（対象イメージ、影響、期限、推奨対応）で提示されることが望ましい。
レポート運用では、未対応の滞留状況、対応時間の分布、再発の有無など、改善に繋がる指標を定期的にまとめる。情報の滞留を防ぐため、誰がいつ見るかという閲覧設計も含めて整える。
3 データと基盤（情報の取り扱い）
3.1 SBOM（ソフトウェア部品表）の活用
3.1.1 SBOM生成のタイミング
SBOMは、イメージを作る過程で生成するのが基本になる。最も有用なのは、依存関係の解決が確定した時点、つまりビルドの再現性が確保される段階である。これにより、後から「どの部品のどの版が含まれているか」を追跡しやすくなる。
また、ベースイメージ由来の情報と、アプリ層で追加した情報を分けて生成できる場合は、統合時の整合も考慮して設計する。生成のタイミングが遅いと、修正の根拠が弱くなり、監査対応に時間がかかる。
3.1.2 SBOMとスキャン結果の突合
スキャン結果とSBOMを突合すると、推定ベースの欠点を補正できる。突合により、SBOMに存在しないパッケージが検出された場合の扱い（スキャン精度の問題か、実際に含まれた未追跡依存か）を判定できる。
さらに、SBOMにある部品がスキャンで見落とされる場合もある。ここではスキャン対象の設定や権限、イメージ展開方法の違いを点検し、検出の欠落を減らす。突合は「一致を確認する作業」であり、単なる照合ではなく運用品質の改善につなげる。
3.2 脆弱性データソース
3.2.1 CVE・ベンダーアドバイザリの参照
脆弱性情報は、CVEのような公開識別子に加えて、ベンダーのアドバイザリを参照して解釈する。CVEは索引として便利だが、影響範囲や緩和策の具体はアドバイザリ側に書かれることが多い。したがって、参照は単一で完結させず、情報を統合する手順を用意する。
また、バージョンの影響条件は微妙に異なることがある。特定リビジョンのみ影響する、設定次第で影響が限定される、といった条件を読み取り、評価に反映する必要がある。
3.2.2 改訂履歴と再評価
アドバイザリは改訂されることがあるため、同じCVEでも解釈が更新される。例えば、初期は限定的とされていた影響が後に広がる、もしくは緩和策が再整理されるケースがある。改訂履歴の追跡を行わないと、対応方針が古い情報に基づいてしまう。
再評価では、対象イメージの構成情報と照らし合わせ直し、優先度の見直しを行う。これにより、不要な対応の増加を避けつつ、真に重要な変更に素早く寄せられる。
3.3 メタデータ管理
3.3.1 イメージ識別子（タグ、ダイジェスト、ビルド情報）
イメージ識別子の管理は、脆弱性管理の再現性に直結する。タグは利用者の視認性が高いが、同一タグに別内容が入りうるため、内容の同一性はダイジェストで担保するのが一般的である。加えて、ビルド番号、生成日時、使用したベースイメージの識別、依存解決の方式なども追跡する。
このメタデータが揃うと、「どの修正がどのバージョンに効いたか」を後から説明しやすい。監査対応だけでなく、障害調査の迅速化にもつながる。
3.3.2 改修履歴・根本原因の記録
改修履歴は、単に「更新した」では不十分である。どの部品をどう更新し、テストや検証をどの範囲で実施し、再発防止として何を変えたかを記録する必要がある。根本原因の記録は、脆弱性が自然増殖したのか、ビルド工程の差分によって混入したのか、あるいは例外運用が蓄積したのかを区別する。
記録が整理されるほど、次回の対応判断が速くなる。結果として、学習が蓄積され、運用が属人化しにくくなる。
4 修正計画と運用設計
4.1 例外・リスク受容の管理
4.1.1 一時的な回避策（緩和策、設定変更）
すぐに修正ができない場合、緩和策を用いてリスクを下げる。緩和策には、機能の無効化、外部公開の制限、認証要件の引き上げ、攻撃面の縮小などが含まれる。設定変更は比較的短期間で可能なことがあるため、一時的な橋渡しとして機能する。
ただし、緩和策は万能ではないため、永続化しない方針が必要になる。実務では「どの条件下で安全側に倒れるか」を明文化し、期限付きであることを明示する。
4.1.2 期限付き例外と承認フロー
例外はリスク受容の一形態であり、無制限に許容すると管理が崩れる。期限付き例外として、いつまでにどのレベルまで是正するかを定め、承認フローで意思決定の根拠を残す。
承認には、技術的妥当性に加えて、運用影響や監査要件の観点が必要になる。期限は現実的な復旧・導入計画と連動させ、過ぎたら自動的に優先度を上げるなどの仕組みを検討する。
4.2 自動化（CI/CDへの統合）
4.2.1 ビルド段階でのゲート
自動化は検出から修正までを早める。ビルド段階でのゲートでは、生成されたイメージに対してスキャンやポリシーチェックを行い、一定条件を満たさない場合は成果物の公開を止める。これにより「脆弱性を含んだまま流れてしまう」事故を減らせる。
ゲートの設計は段階的に行うのが現実的である。最初は参照用途（警告）から始め、データが揃った後にブロック条件を調整することで、運用の急変による混乱を抑える。
4.2.2 デプロイ前審査とポリシー
デプロイ前の審査は、実行環境への影響を考慮する段階である。ここでは、対象環境の重要度、ネットワークの露出度、例外の有効期限などをポリシーとして統合し、投入可否を判断する。
ポリシーは「静的に見つかったら止める」のような単純化を避け、評価結果と運用条件を結び付ける。これにより、例外の扱いや緩和策の可否も含めた、実務に即した意思決定が可能になる。
4.3 組織体制と責務
4.3.1 開発、運用、セキュリティの役割分担
役割分担が曖昧だと、対応が遅れたり責任が押し付け合いになったりする。開発は依存更新や修正の実装、運用は配布・展開・設定管理、セキュリティは評価基準や優先度ルールの整備、監視設計を担うと整理しやすい。
また、例外を扱う場では意思決定者を明確にする。技術判断だけでなく業務影響の評価が必要になるため、権限と責務の線引きを事前に共有することが重要である。
4.3.2 監査・説明可能性（根拠の提示）
説明可能性は、なぜその修正を選び、なぜその期限になったのかを示す力である。監査では、対象イメージ、脆弱性情報の出典、評価に用いた条件、緩和策の根拠、テスト状況が問われやすい。
そのため記録は、チケットやレポートの形で一貫して追跡可能にする。単なるログの蓄積ではなく、読み手が理解できる構造で残すことが、監査対応を効率化する。
5 参考手順とベストプラクティス
5.1 ベースイメージ運用
5.1 最小化（スリム化）と更新頻度
ベースイメージは攻撃面の土台になるため、最小化（スリム化）と更新頻度を意識する。不要なパッケージや開発ツールを含めないことで、スキャン対象の広がりを抑え、修正工数を減らせる。加えて、頻繁に更新できる仕組み（定期ビルド、依存の更新自動化）を整えると、新規欠陥への追随が早くなる。
ただし、過度に削ると運用に必要な要素が不足し、復旧が難しくなる可能性がある。目的は「必要なものだけを残す」ことであり、運用要件とバランスを取る必要がある。
5.1.2 信頼できる供給元の選定
信頼できる供給元の選定は、後工程の手戻りを減らす。ベースイメージを提供するプロジェクトやベンダーの更新体制、署名や検証の仕組み、脆弱性対応の透明性を評価基準として扱うとよい。
また、自組織で再ビルドする場合は、取得経路の追跡と検証を組み込む。供給元の選定は一度きりではなく、提供品質の変化に応じて見直しを行う。
5.2 依存関係の管理
5.2.1 バージョン固定と更新方針
依存関係のバージョン固定は、再現性と予測可能性を高める。自動更新を完全に禁止すると脆弱性の解消が遅れるため、固定と更新の運用ルールを組み合わせる。例えば、定めた周期で更新し、その都度スキャン・検証を行う方式が多い。
更新方針では、重要度の高い部品から優先すること、互換性に注意すること、必要なら段階導入することを示す。これにより、更新が「怖いイベント」にならず、計画に組み込まれる。
5.2.2 不要部品の削除
不要部品の削除は、脆弱性の種そのものを減らす対策である。ビルド時にのみ使用するツールを実行イメージへ持ち込まない、依存ツリーを見直し、機能に関係ないライブラリを落とす、といった方針が該当する。
削除は単に依存を減らすだけでなく、ビルド工程と生成成果物を分離する設計と相性がよい。結果として、更新時に検証対象の範囲が縮まり、回帰確認も軽くなる。
5.3 継続的な改善
5.3.1 インシデントからのフィードバック
継続改善の起点は、インシデントや重大な見落としから得られる学びである。例えば「本番で初めて影響が判明した」場合、その原因がスキャン頻度不足なのか、SBOMの欠落なのか、例外の管理不備なのかを分解して記録する。
フィードバックはルールや自動化へ反映する。具体的には、検出スコープの変更、優先度計算の見直し、ゲート条件の強化、例外の承認手順の調整などが候補になる。
5.3.2 成果指標（検出までの時間、未対応期間など）
成果指標は、速度だけでなく質を測る形にすると機能しやすい。検出までの時間 (time to detect) や通知から対応開始までの時間、未対応が残った期間 (time to remediate) などが代表的である。
さらに、再発率（同種の脆弱性が繰り返し残る比率）や、例外の期限超過件数、検証漏れによる手戻り回数も指標として有効になる。指標が現場の行動に繋がるよう、レポートのタイミングと責任部署を紐付ける。
6 ユーモアを交えた理解促進（学習・定着）
6.1 「見つけたら終わり？」を防ぐ発想の転換
脆弱性管理は、スキャン結果を見て安心する“宝探しごっこ”で終わらないことが肝要である。見つかったのはゴールではなく、次に来る「理解」「優先」「修正」「検証」の入口に過ぎない。
たとえば、宝があるとしても封を開けずに棚に戻すだけなら意味は薄い。評価で影響範囲を確かめ、必要な手当を施し、最後にちゃんと閉じ直す。こうした比喩で、プロセスの連続性をチームの共通認識にする効果がある。
6.2 よくある誤解と“あるある”対策
誤解として多いのは、「CVEがある＝即時に危険」と短絡する点である。実際には露出や設定、到達経路が条件になるため、評価工程を省くと判断を外しやすい。対策は、影響度算定の手順を固定し、運用情報を必ず紐付けることにある。
もう一つの誤解は、「更新したから大丈夫」を再スキャンや回帰確認なしで済ませてしまう点である。アプリや依存が変わると別の欠陥や互換性問題が出ることがあるため、再評価を前提化する。さらに、例外のまま放置することを“いつか直す”で終えないよう、期限と承認フローを整備するのが実務上の定番となる。
6.3 チームで回すコミュニケーション手段
脆弱性管理は分業が前提になるため、連絡の形を整えると回りやすい。例えば、セキュリティは評価基準を共有し、開発は修正方針と見込み時期を提示し、運用は展開計画と検証結果を返す、という往復をチケットやスレッドで可視化する。
また、意思決定を早めるために「判断材料のテンプレート」を用意する方法がある。対象イメージ、根拠、期限、提案された対応、想定される影響などを揃えると、会話が迷走しにくい。最後に、チーム内の軽い定例（進捗共有の短縮版）を設けると、滞留が目立ちやすくなる。