DockerはDocker Hardened Images、ソフトウェアサプライチェーンの脅威から保護するために設計された、エンタープライズグレードでセキュリティ強化されたコンテナイメージのカタログ、をリリースした。Dockerによれば、DevOpsチームが自らコンテナのセキュリティを確保する手間を省くことで、Hardened Imagesはエンタープライズグレードのセキュリティおよびコンプライアンス標準を満たすより簡単な方法を提供する。
Hardened Imagesはイメージコンポーネントが改ざんされていないこと、悪意のあるコードを含んでいないことに対するチームの信頼を高めることを目的としている。加えて、開発者がベースイメージから始めてパッケージを段階的に追加することが一般的だが、これにより攻撃対象が拡大し、不必要または古くて正しくない依存関係が導入されることがよくある。
Docker Hardened Imagesはセキュリティを念頭に置いて構築されており、単なる「既存コンテナの縮小版」ではない：
これらのイメージは単なるスリム化や最小化を超えたものです。Docker Hardened Imagesは攻撃対象領域を最大95%削減し、最初から露出を制限します。
この目的のためにDockerはDocker Hardened Imagesが開発時には有用だが、本番環境では攻撃対象領域を拡大するシェル、パッケージマネージャ、デバッグツールなどの不要なコンポーネントを排除すると説明している。開発者は引き続きDocker UIを使用して証明書、パッケージ、スクリプト、構成ファイルを追加することで、これらのイメージをカスタマイズするオプションを利用可能だ。
例えばNode hardened imageは、標準のNodeイメージと比較して全体のパッケージ数を98%削減している。
パッケージの数を減らすことは「ゼロ脆弱性」ポリシーに準拠するための労力も軽減させる。Sysdigの2023年クラウドネイティブセキュリティおよび使用状況レポートによると、報告された未修正の重大および高深刻度の脆弱性のうち、ランタイムで使用されるパッケージに影響を与えるのはわずか15%だ。しかし、使用されていない脆弱なパッケージも全体の脆弱性数に含まれるため、コンテナイメージの87%が重大または高深刻度の脆弱性を含むことになる。Hacker Newsのユーザーkoblas氏が指摘したように、これはイメージが厳密に必要なパッケージのみを含むシナリオと比較してパッチを適用しなければならないイメージ数を増加させている。
古典的UNIX問題は、LPTプリンタデーモンに問題がある（実際にたくさんあった）ことでした。しかし、どのシステムもLPTを実行していなかったのに、あなたはセキュリティポリシーを維持するためだけに1,000台以上のシステムにパッチを適用しなければなりませんでした。
フルUNIXシステムとDockerの違いは、スクラッチイメージをベースにコードをデプロイできる可能性があることです。本番稼働に必要な部分だけを持つシステムを想像してみてください。セキュリティ例外レポートはゼロになるでしょう。
さらにDockerはアップデートがリリースされた場合や依存関係に対して新しいCVEが公開された場合に、Hardened Imagesを再構築することを約束している。すべての新しいビルドはDockerのSLSA Build Level 3に準拠したビルドシステムに基づいて、新しい証明書を取得する。
私たちは重大および高深刻度のCVEには7日以内にパッチを適用し—これは業界の一般的な対応時間よりも速い－、それをエンタープライズグレードのSLAでサポートしています。
Dockerはほとんどの開発者にとって、Hardened Imagesへの移行はDockerfileのFROM句を変更するのと同じぐらいシンプルだと主張している。すでにDebianまたはAlpineベースのイメージを使用している開発者は、Hardened Imagesが両方をサポートしているため、違和感を感じないだろう。
DockerはHardened Imagesの唯一の提供者ではない。セキュリティソリューションプロバイダーのChainguardも1,300以上のHardened Imagesのカタログを提供している。
Hardened base imageの利用はコンテナのセキュリティ確保の一部にすぎない。コンテナをより包括的にハードニングするための主要なベストプラクティスも検討することをお勧めする。