Dockerイメージのセキュリティ強化：リスクの把握から継続的なパッチ管理まで

【なぜ重要か】 Dockerイメージの脆弱性の大半は、アプリ自身のコードではなく、ベースイメージに含まれるOSSパッケージやライブラリに起因する。イメージはビルド時点ではクリーンでも、その後に新たな脆弱性が日々発見されるため、一度スキャンしただけでは継続的な安全性を保証できない。バージョンを固定したまま放置すれば未修正の脆弱性が蓄積し、常に最新版へ追従すれば破壊的変更やxz-utilsバックドアのような新リリース固有のリスクにさらされるという、両面のトレードオフを理解した管理が求められる。

【ポイント】

• 攻撃面の最小化：マルチステージビルドでビルドツールを最終イメージに含めない。ディストロレスやAlpineなどの最小ベースイメージを選択し、実行時に不要なシェル・cURL・wget等のパッケージを削除する。ベースイメージの選択がもっとも高レバレッジな判断となる。
• 権限・ケーパビリティの制御：コンテナをroot以外のユーザーで実行し、ルートファイルシステムを読み取り専用にする。CAP_NET_RAWなど使用しないLinuxケーパビリティは明示的に削除し、必要なものだけを追加する。
• シークレット・ファイル管理：ARGやCOPYでシークレットをレイヤーに書き込まない（後のレイヤーで削除しても履歴に残る）。ビルド時はシークレットマウントを使用し、実行時は専用のシークレットマネージャーから注入・ローテーションする。.dockerignoreで不要ファイルがビルドコンテキストに入らないようにする。
• バージョン固定と継続的な再検証：タグではなくダイジェスト（@sha256:...）でベースイメージを固定して決定論的なビルドを確保する。ただし固定したまま放置せず、新規CVE開示のたびに影響有無を継続的に確認する。実行中のコンテナはイミュータブルに扱い、修正が必要な場合は新イメージをビルド・テスト・再デプロイする。
• ベースイメージのパッチ適用方式は3種類：①自前で維持管理（制御は完全だが工数大）、②ベンダー提供の別ディストリビューションへ移行（テスト・互換性コストが発生）、③現行バージョンのまま修正済みビルドを受け取る方式。Aikido Securityは3つ目のアプローチを採用し、既存のベースイメージバージョンのままCVEを修正した新規ビルドをPR形式で提供する。これにより、バージョン移行や破壊的変更なしに脆弱性を解消できる。

【まとめ】 Dockerイメージのセキュリティは「ビルド時の一度限りの対応」ではなく、攻撃面の最小化・権限制御・シークレット管理・継続的なパッチ適用を組み合わせた継続的な脆弱性管理の問題である。固定バージョンを維持したまま安全性を保ちたいチームは、Aikidoが提供する「同一バージョンの修正済みビルドをPRで受け取る」アプローチの導入を検討するとよい。