【クラウドネイティブ会議】コンテナイメージの脆弱性をどう減らすか ―― 依存関係を最小化する新たな安全設計

クラウドネイティブ会議のセッション「脆弱性を削減し、安全なコンテナイメージを作るための新しいアプローチ：Hardened Container」では、Docker, Inc.のStrategic Solutions Engineerである根本征氏が、コンテナイメージに潜む依存関係と脆弱性の問題を解説した。OSや言語ランタイム、各種ライブラリなど多数のOSSを含むコンテナイメージは、ソフトウェアサプライチェーン攻撃の標的になりやすい。本セッションでは、安全なイメージを選ぶ基準に加え、依存関係や攻撃対象領域を最小化する「Hardened Container Images」を紹介。Docker Hardened Imagesへの移行デモを交えながら、脆弱性を後から追いかけるのではなく、初めから安全性を高めるアプローチを示した。

多数の依存関係が広げるコンテナの攻撃対象領域

コンテナイメージは、開発者が作成したアプリケーションコードだけで構成されているわけではない。ベースイメージに含まれるOSや言語ランタイム、OSパッケージ、npmやpipなどで導入するアプリケーションの依存パッケージを含め、多数のOSSで構成される。

Docker, Inc.のStrategic Solutions Engineerである根本征氏は、Node.jsアプリケーションのDockerfileを例に、その構造を説明した。ここではベースイメージとして「node:20-alpine」を指定し、curlなどのOSパッケージを追加し、npmを通じて依存パッケージをインストールする。開発者が直接選んだものだけでなく、その内部の依存関係まで含めて一つのコンテナイメージが作られるのである。「コンテナイメージは、自分が作ったアプリケーションコードだけではなく、多数のオープンソースのコンポーネントを含めてパッケージしていきます」と根本氏は説明した。

こうした依存関係の中に改ざんされたコンポーネントや脆弱性が含まれていれば、自社のアプリケーションも影響を受ける。攻撃者から見れば、一つの広く利用されているパッケージを改ざんするだけで、多数のアプリケーションへ影響を及ぼせる。これがソフトウェアサプライチェーン攻撃の怖さである。

セッションでは、近年CVEの報告数が急増し、サプライチェーン攻撃も深刻化していることが示された。一方で、修正版が公開されても利用者側で更新されないケースが多いという。Sonatypeの調査では、問題のあるOSSコンポーネントの99.5％には修正版が提供されており、適切に更新していれば、ほとんどのリスクを防げたとされる。しかし、80％以上のアプリケーションでは依存関係が1年以上更新されていなかった。また、Log4Shellの公開から3年以上経過した後も、影響を受けるバージョンが13％程度ダウンロードされていたという。

利用者の慢心 Complacency)によるリスクの放置・拡大

コンテナイメージでは、ベースイメージに含まれるシェルやパッケージマネージャーなど、実行時には不要なコンポーネントも攻撃対象領域を広げる。しかも、開発者がベースイメージの内部を直接修正することは難しく、修正版の公開を待つか、別のイメージへ置き換える必要がある。

発行元が不明確なイメージには、公式を装ったタイポスクワッティングや、マルウェア、バックドアが仕掛けられる危険もある。これはベースイメージに限らず、PostgreSQLやNGINX、Redisなどのサードパーティーイメージを本番環境で動かす場合にも共通する問題である。

安全なイメージ選定を組織全体で標準化する

根本氏は、安全なイメージを選ぶ基準として二つのポイントを挙げた。

一つ目は、信頼できるパブリッシャーから提供されたイメージを選ぶことである。Docker Hubでは、Dockerと開発元が共同で保守する「Docker Official Images」、パートナー企業が提供する「Docker Verified Publisher Images」、そしてDockerが支援するOSSプロジェクトの「Docker Sponsored OSS Images」などが提供されている。もう一つは、必要最小限のコンポーネントで構成されたイメージを選ぶことである。代表例にはSlim、Alpine、Distrolessがある。不要なパッケージを削減することで、依存関係と潜在的な脆弱性を減らせるが、Alpineでは互換性、Distrolessではデバッグの難しさが課題となる。「現在のサプライチェーンセキュリティの状況を考えると、特に本番環境で動かすイメージは、Distrolessのような状態まで持っていくことが望ましいです」と根本氏は語った。

ただし、発行元が明確でも、依存関係や脆弱性が少ないとは限らない。最小構成のイメージでも、新たな脆弱性への対応速度までは保証されない。またDistrolessは主要な言語ランタイムが中心で、データベースやWebサーバーまで含めた統一的な選定は難しい。組織全体で安全なイメージを選ぼうとすると、ルールが複雑になり、統制が効きにくくなる。

この課題に対するアプローチが「Hardened Container Images」である。信頼された発行元が提供し、実行に不要な依存関係を大幅に削減することで、既知のCVEをほぼゼロに近づける。製品によっては、脆弱性が発見された際の修正時間をSLAとして保証する。

Hardened Container Images

代表例として、コンテナ向けOS「Wolfi」を採用するChainguard Containersと、Dockerが提供するDocker Hardened Images（以下、DHI）が紹介された。Chainguard Containersは2000以上のイメージを提供し、CVE修正のSLAやEOL後の猶予期間を設けている。

DHI Enterpriseも2000以上のイメージを提供し、AlpineやDebianとの互換性を維持しながら、依存関係と脆弱性を削減する。Dockerfileを大きく変更せずに移行しやすい点が特徴である。

脆弱性対応の例として、golang.org/x/crypto/sshに影響する三つのCVEが公表された際、DHI Enterpriseは24時間以内に修正版を公開した。これはCVE情報を継続的に取り込み、SBOMを基に影響するイメージを判定し、自動化されたパッチワークフローを実行することで実現している。

さらに2025年12月には、Apache License 2.0で公開されるDHI Communityの提供も始まった。迅速なパッチ提供やSLA保証はEnterprise版の領域となるが、2000以上のイメージを無償で利用可能で、Hardened Container Imagesを導入する入口となり得るだろう。

移行と多層防御でコンテナをさらに強化する

後半のデモでは、Node.jsアプリケーションとPostgreSQLを例に、既存イメージからDHIへ移行する方法が示された。

Node.jsの例では、公式のAlpineイメージをDHIのDevバリアントへ変更した。Alpineとの互換性があるため、基本的にはDockerfileのFROMで指定するイメージパスを置き換えるだけで移行できる。「Devバリアントにはシェルやパッケージマネージャーなども含まれています」と根本氏は説明した。

そこで、ビルドにはDevバリアントを使い、本番用イメージにはRuntimeバリアントへ成果物だけをコピーするマルチステージビルドを採用した。その結果、脆弱性と不要なコンポーネントを減らし、イメージサイズも約600MBから約300MBへと削減できた。

PostgreSQLでも、公式イメージからDHIへパスを変更することで、クリティカルを含む複数の脆弱性が大幅に削減された。言語ランタイムだけでなく、データベースやWebサーバーも同じ方針で置き換えられるため、組織として利用するイメージを統制しやすくなる。

さらに根本氏は、イメージを強化する二つの方法を紹介した。一つは「Docker Hardened System Packages」である。Dockerが1万以上のOSパッケージをソースコードからビルドし、署名とセキュリティ強化を行う。DHIはCommunity版を含め、これらのパッケージを基に構成され、OSパッケージの改ざんを狙った攻撃への耐性を高める。

Docker Hardened System Packages

そしてもう一つは「Socket Firewall」である。npmやpipなどが依存ライブラリをダウンロードする前に、潜在的なマルウェアや悪意のあるパッケージを検出し、ブロックするというものだ。DHIではNode.jsやPython、RustなどのランタイムにSocket Firewallを組み込んだイメージが提供されている。

根本氏は、脆弱性を検出してから個別に対応するだけでは、「依存関係の多さや更新負荷によって対応が遅れやすい」点を指摘した。不要な依存関係を初めから減らしたHardened Container Imagesに、OSパッケージの強化と依存関係インストール時の保護を組み合わせることで、「後追いではない」コンテナセキュリティを実現できるのである。