コンテナセキュリティには、昔から変わらない課題があります。チームは脆弱性を特定できても、その結果をリスク低減につなげるのははるかに困難です。標準的なコンテナイメージには、OSパッケージ、開発ツール、デバッグ用ユーティリティ、そしてアプリケーションが一切使用しないライブラリが含まれていることがあります。不要なコンポーネントが増えるたびに攻撃対象領域が広がり、調査、パッチ適用、監査時の説明が必要な脆弱性も増えていきます。
たとえば、ダウンロードした直後の状態で、分類済みの脆弱性が274件にのぼるNGINXイメージがあるとします。スキャンを行えば検出結果は可視化されますが、一覧を見てもワークロードが実際にどのコンポーネントを実行しているかはわかりません。安全に取り除く方法も示されません。本当のセキュリティ上のチャンスは、単に指摘事項を増やすことではなく、アプリケーションを止めることなく、イメージに含まれるものを減らすことにあります。
これまで、チームはこの課題に手作業で取り組んできました。開発者がイメージを調べ、どのパッケージやライブラリ、ツールが不要に見えるかを自らの判断で見極めます。しかしこの方法は規模の拡大が難しく、担当者が替わると再現も困難です。本番環境にイメージが到達した場合のリスクも大きくなります。静的なレビューでは未使用に見えるコンポーネントが、高負荷時や特殊なトランザクション、あまり実行されないアプリケーションの処理経路で必要になる場合があるからです。リリース後にイメージが動作しなくなれば、数個のパッケージを削除した効果を、障害のコストが上回りかねません。
脆弱性スキャンから実行時の証拠へ
解決策は、推測に頼る作業を、振る舞いを考慮したハードニングに置き換えることです。基本原則は明快です。インストールされているものが、実行されているものとは限りません。静的解析とソフトウェア部品表（SBOM）は、イメージに何が存在するかを示します。実行時の観測は、ワークロードの稼働中に実際に使われるコンポーネントを特定するという、異なる視点を加えます。
この違いが、実行時部品表（RBOM）の基礎となります。RBOMは、計装されたコンテナで使用が確認されたソフトウェアコンポーネントを記録したものです。SBOMと並べて見ることで、インストールされているコンポーネントの全体像と、実行時に確認された部分集合を区別できます。どちらの視点も重要です。SBOMは資産管理やコンプライアンス対応に役立ち、RBOMは観測された振る舞いに基づくハードニングの判断材料になります。
コンテナイメージを3ステップでハードニングする方法
再現可能なハードニングのプロセスは、プロファイル、ハードニング、検証の3段階で構成されます。
第1に、代表的な条件下でワークロードをプロファイリングします。単純な「正常系」のテストにとどまらず、機能テストスイート、ステージング環境のトラフィック、適切な場合は本番環境での利用、負荷・ストレステスト、ファジングも含める必要があります。目的は、アプリケーションが何を読み込み、どのバイナリを実行し、どの設定を使い、どのようなネットワーク呼び出しを行うかについて、信頼できるベースラインを取得することです。このベースラインの質が、完成するイメージの質を直接左右します。
第2に、このベースラインを基に削除を進めます。実行経路マップがあれば、プロファイリング中に観測されなかったコンポーネントを判断する根拠になります。削除の強度は、サービスの内容とリスクプロファイルに合わせて選べます。標準的なアプローチでは、実行で観測されなかったコンポーネントを削除します。より保守的なアプローチでは、既知の脆弱性を持つ未使用パッケージに絞ります。より積極的なアプローチは、大幅な削減を許容できるリスクの低い社内サービスに向いているでしょう。正当な理由がある場合にコンポーネントを残せるよう、明示的な保持リストや上書きリストを用意することも重要です。
第3に、ハードニング済みのイメージを昇格させる前に検証します。機能テストと統合テストを再実行し、元のイメージと結果を比較したうえで、ロールバック用に元のイメージを保持します。検証は任意の最終チェックではなく、リリースゲートとして位置づけるべきです。ハードニング済みイメージが検証に失敗した場合は、原因を把握して解決するまで先へ進めてはなりません。検証で得られた知見は、次回のプロファイリングのベースラインにも反映し、プロセスを継続的に改善していきます。
再現可能なハードニングのプロセスがもたらす効果は、決して小さくありません。不要なコンポーネントを取り除けば、アプリケーションのソースコードやロジックを変更することなく、リスクへの露出と運用上の負荷の両方を減らせます。
CI/CDでコンテナハードニングを自動化する
自動化により、このプロセスを大規模に再現できるようになります。プロファイリング、実行経路の取得、イメージの再生成、検証、ドリフト検知は、GitHub Actions、GitLab CI、JenkinsといったCI/CDシステムに組み込めます。新しいビルドで、これまで観測されていなかったコンポーネントが使われ始めた場合や、以前使われていたコンポーネントが消えた場合には、パイプラインが変更をレビュー対象として通知できます。さらに、フリート全体のダッシュボードで、ハードニング済みのイメージ、未対応のイメージ、そしてどのような判断が下されたかを確認できます。
ただし、自動化によって人間の説明責任をなくしてはなりません。削除の強度の選択、例外の管理、検証失敗の調査、コンプライアンス上重要なリリースの承認は、引き続きセキュリティチームとエンジニアリングチームが担う必要があります。すべてのサービスに合う単一のプリセットは、まず存在しないでしょう。外部に公開されたサービスには、より保守的で監査しやすい方法が求められる一方、社内サービスではより積極的な削減が可能かもしれません。状況に応じた判断と承認は、今後も欠かせません。
コンテナのハードニングは、一度きりの掃除ではありません。パッケージや依存関係の進化に伴いイメージも変化するため、該当するビルドのたびにベースラインと検証のプロセスを繰り返す必要があります。組織はまず1つのサービスを選び、ハードニング前後のイメージを計測して、必要な機能が損なわれていないことを確認するところから始められます。より大きな教訓は、根拠に基づき継続的に検証された手順で不要なソフトウェアを減らすことで、セキュリティが向上するという点です。脆弱性レポートをただ積み上げるよりも、はるかに意義のある取り組みです。安全なイメージには、ワークロードが必要とするものだけを含め、プロセスが安全に正当化できる範囲を超えて含めるべきではありません。
翻訳元: https://www.helpnetsecurity.com/2026/11/04/rapidfort-runtime-container-profiling/
