コンテナイメージの脆弱性を削減する新しいアプローチ：Hardened Container Images

多数の OSS で構成されているコンテナイメージは、近年急増する脆弱性を狙ったサプライチェーン攻撃の主要な標的となっています。

一方で、イメージスキャンやアラートを導入しても、脆弱性や依存関係の多さから対応が後回しになってしまったり、修正対応が開発者の大きな負荷となっているケースも少なくありません。

このような課題に対し、脆弱性や依存関係を最小化したデフォルトで安全なコンテナイメージ「Hardened Container Images」の採用が注目を集めています。

本セッションでは、Docker が 2025 年 12 月に Apache 2.0 ライセンスのオープンソースとして無償提供を始めた「Docker Hardened Images (DHI)」を一つの実践例として、コンテナイメージにおける脆弱性がなぜ削減しづらいのか、そして Hardened Container Images がどのように「後追いではない」サプライチェーンセキュリティを実現できるのかを解説します。

コンテナアプリケーションを開発・運用するエンジニアが、日々の開発フローの中で無理なくセキュリティを向上させるための考え方と具体的なアプローチを持ち帰っていただくことを目的としています。

Transcript

1. DevOpsDays Tokyo 2026 Tadashi Nemoto Strategic Solutions Engineer, Docker コンテナイメージの脆弱性を削減する 新しいアプローチ Hardened Container Images
2. 自己紹介 複数の日系企業でテスト自動化エンジニア ・DevOps エンジニアとして活動した後、 プリセールスエンジニアとして DevSecOps、 CI/CD、自動テストを中心にお客様の技術支援や 情報発信を行ってきました。2024 年 8 月に日本 拠点 1 人目のプリセールスエンジニアと して Docker に入社。 tadashi-nemoto tadashi0713-dev tadashi0713.dev
3. このセッションの概要 多数の OSS で構成されているコンテナイメージは、近年急増する脆弱性を狙ったサプライチェーン 攻撃の主要な標的となっています。 一方で、イメージスキャンやアラートを導入しても、脆弱性や依存関係の多さから対応が後回しに なってしまったり、修正対応が開発者の大きな負荷となっているケースも少なくありません。 このような課題に対し、脆弱性や依存関係を最小化したデフォルトで安全なコンテナイメージ 「Hardened Container Images」が注目を集めています。 本セッションでは、Docker が 2025 年 12 月に Apache 2.0 ライセンスのオープンソースとして無償提供を 始めた「Docker Hardened Images (DHI)」を一つの実践例として、コンテナイメージに おける脆弱性がなぜ削減しづらいのか、そして Hardened Container Images がどのように 「後追いではない」サプライチェーンセキュリティを実現できるのかを解説します。
4. アジェンダ • コンテナイメージに含まれる依存関係と脆弱性 • 近年のソフトウェアサプライチェーン攻撃 • コンテナイメージの脆弱性が削減しづらい原因 • 安全なベースイメージを選択する基準と Hardened Container Images • Hardened Container Images への移行方法(デモ) • まとめ
5. コンテナイメージに含まれる 依存関係と脆弱性
6. FROM node:20-alpine WORKDIR /app RUN apk add --no-cache curl COPY . . RUN npm install --production EXPOSE 3000 CMD ["npm", "start"] Dockerfile アプリケーションの依存パッケージ (npm, pip, Maven, RubyGem など) をインストール 必要な OS パッケージを個別に インストール OSAlpine Linux)とランタイム Node.js)、それに必要な依存関係がイ ンストールされたベースイメージを利用
7. ソフトウェアサプライチェーン攻撃 コンテナイメージには、多くの OSS の依存関係を含む ことになり、その依存関係の中に (意図的にインストー ルしていなくても)脆弱性が含まれている場合、自分た ちのコンテナイメージにも影響を受ける 1つのパッケージを改ざん・脆弱性を悪用するだけで、 (意 図的にインストールしていないものも含め )多くのアプリ ケーションに悪影響を与えることが できる https://anchore.com/software-supply-chain-security/what-is-sscs/
8. $ docker run -e POSTGRES_PASSWORD=dev \ -p 5432:5432 postgres:17.1 $ psql -h localhost -U postgres CLI サードパーティーのイメージを本番環境などで動かした場合にも、 この依存関係・脆弱性の問題は残り続ける
9. 近年のソフトウェアサプライチェーン攻撃
10. 脆弱性(CVEs)の急増とサプライチェーン攻撃の深刻化
11. Log4j(CVE-2021-44228, Log4jShell) https://xtech.nikkei.com/atcl/nxt/column/18/00001/06457/ 2021年末に明らかになったJavaのログ出力ライブラリー「Apache Log4j」の脆弱性が、ランサム ウエア（身代金要求型ウイルス）攻撃に悪用され出した。米Microsoft（マイクロソフト）は2022年1 月10日、Log4jの脆弱性を悪用する新手のランサムウエア「Night Sky」が広まっていると明らか にした。 　同社によれば、中国に拠点を置くサイバー犯罪者集団（マイクロソフトは「DEV-0401」と呼称） がNight Skyを使って、米VMware（ヴイエムウェア）の仮想デスクトップ構築用ソフト「VMware Horizon」を標的とする攻撃を2022年1月4日にも開始したという。VMware HorizonはLog4jのコ ンポーネントを含んでいる。不正侵入された企業はNight Skyを社内に展開されるという。 　Night Skyは既に「戦果」を上げているもようだ。同犯罪者集団は情報システムの設計・構築や 電気工事を手掛ける東京コンピュータサービス（東京・文京）を2021年12月に攻撃し、ファイル サーバーに保管されていた130ギガバイトのデータなどを盗んだと主張。「第1弾」として、数ギガ バイトのデータを闇サイトに暴露した。サイバーセキュリティーの専門家によると、IT大手や自動 車大手、金融機関などとの取引情報が含まれるという。
12. XZ Utils バックドア(CVE-2024-3024) 2024年3月、複数の Linux ディストリビューションなどで利用されているファイ ル可逆圧縮ツールである XZ Util で悪意のあるコードが挿入された。 • インストールされたシステムでは、特定条件下で SSH ポート経由で 外部から攻撃者が接続できるような改ざんが行われた • ハッカー(Jia Tan)は開発者コミュニティ (GitHub)で積極的な貢献を 行い信頼を獲得したのち、メンテナンス権限を用いてバックドアを仕 込んだ • 多くの Linux ディストリビューションが影響 ◦ Debian ◦ Red Hat ◦ Arch Linux ◦ Alpine Linux ◦ SUSE / openSUSE ◦ Ubuntu
13. MongoDB(CVE-2025-14847, MongoBleed) 2025 年 12 月に発見された、MongoDB Server がネットワーク通信を処理 する初期段階で、zlib 圧縮メッセージのバッファ管理を誤ることにより発生 する情報漏洩脆弱性 攻撃に認証が一切不要なため、インターネット上に公開されている対象の MongoDB サーバー(ポート27017)にアクセス可能であれば、誰でもサー バーのメモリ情報を盗み見ることができてしまう。漏洩するメモリ情報には、 そのサーバーが処理していた他のユーザーの直近のデータ、認証用のセッ ションID、APIキー、あるいは平文のパスワードそのものなど、極めて機密 性の高い情報が含まれる可能性がある。 影響を受ける範囲も広く、MongoDB のバージョン 4.4、5.0、6.0、7.0、8.0 といった主要なバージョンの多くがこの問題を含んでいた。 既に世界中で 8,7000 台の MongoDB サーバーがインターネット上に無防 備な状態で露出しており、ゲーム大手 Ubisoft の大規模な侵害にも関連し ていることが判明した。 https://xenospectrum.com/mongobleed-cve-2025-14847-mongodb-exploit-ubisoft-breach/
14. 利用者の慢心 Complacency)による リスクの放置・拡大 99.5% 修正版が提供された OSS コンポーネント 適切に対応できていれば、 ほとんどのリスクは防げたも の 80% 以上 アプリケーション 依存関係が1年以上 アップデートされて いない sonatype: 10th Annual State of the Software Supply Chain 13% Log4Shell 公開から3年 以上経過した後にも、 影響のあるバージョンがダ ウンロード
15. コンテナイメージの脆弱性が 削減しづらい原因
16. 主なコンテナイメージスキャン・アラートツール Trivy 元々日本の個人開発者 (福田哲 平氏)が開発したオープンソース ツールを Aqua Security 社に 買収・譲渡 された CLI で主にローカル開発環境や CI/CD パイプラインで 手軽に利用することができる Docker Scout Docker 社が提供する コンテナイメージ分析 ソリューション Docker Desktop に内蔵され ており、一部無償で利用可能 CLI・GUI どちらとも提供されて おり、ローカル開発環境、 CI/CD パイプライン、Docker Hub などのコンテナレジストリ でリアルタイム 分析を行える コンテナレジストリに付属 したスキャン機能 Amazon ECR、Google Artifact Registry、Azure Container Registry など 主要なクラウドプロバイダーのコ ンテナレジストリに付属したイ メージスキャン機能 セットアップはしやすいが、ロー カル開発環境や CI/CD パイプ ラインでの分析が困難になりが ち Sysdig Secure Sysdig 社が提供する CNAPP の一部機能 本番環境で稼働中のコンテナを 継続的にスキャンし、 新しい CVE が公開された際に 即座に該当コンテナを特定でき る Docker Scout との統合によっ て、ビルド内容と本番 環境での実行結果を比較するこ とが可能
17. スキャン・アラート ツールを導入したが、 大量の脆弱性対応 に追われる
18. FROM node:20-alpine WORKDIR /app RUN apk add --no-cache curl COPY . . RUN npm install --production EXPOSE 3000 CMD ["npm", "start"] Dockerfile ➔ シェルやパッケージマネージャーなどアプ リケーション実行には必要ない コンポーネントが、潜在的な脆弱性の総数 を増加させる ➔ 開発者自身で中身を修正したり、 脆弱性パッチすることが難しい ➔ 一般的には開発者コミュニティが 作成・メンテナンスしているため、 脆弱性対応がボランティアベース ➔ 発行元が不明確だと、マルウェアの 混入やバックドアが仕掛けられる 可能性も
19. 安全なイメージを選択する基準と Hardened Container Images
20. 安全なイメージを選択する基準 信頼できるパブリッシャーから イメージを選択する 発行元が不明確なイメージを排除する ことによって、公式を装った悪意のあるイメー ジ(タイポスワッピング)や マルウェアの混入・バックドアが仕掛けられ たイメージを未然に防ぐ 必要最小限のコンポーネントで 構成されたイメージを選択する 汎用的な OS イメージFull OSには アプリケーションの実行自体には不要なパッ ケージ(シェル、コンパイラ、 パッケージマネージャー等 )が含まれており、 それらを削減したイメージを利用することで、 攻撃対象領域や潜在的な 脆弱性の総数を削減できる 脆弱性の少ない・迅速な対応を するイメージを選択する Hardened Container Image) コミュニティによるボランティアベースの脆弱 性対応ではなく、「Zero CVE」を目標に掲 げ、脆弱性対応の SLA が 保証されているイメージによって、 コンプライアンス遵守とセキュリティ リスクの最小化を実現
21. 　 Docker Hub で信頼されたイメージを利用する Docker Official Image Docker の専任チームと アップストリームメンテナ (開発 元が)共同でメンテナンスしてい るイメージ 定期的な脆弱性スキャンも 実施 Docker Verified Publisher Image Docker とパートナーシップを結 んだ企業(ベンダー)が 提供し、その身元が証明されて いるイメージ Docker Sponsored OSS Image 世界中で広く利用されている OSS プロジェクトに対し、 Docker がスポンサーとして支 援しているイメージ Community Image コミュニティや個人開発者 などによって提供される イメージ メンテナンスが放置されて いるものや、セキュリティ上 問題があるものも混在
22. 必要最小限のコンポーネントで構成されたイメージを選択 Full OS Debian, Ubuntu) 標準的な Linux ディストリ ビューションをそのまま コンテナイメージ化したもの 高い互換性を持っており、 一般的な Linux 環境に含まれ る多くのツールが含まれている ため、トラブルシューティングが 容易 一方でサイズも大きく、含まれる パッケージも多いため、セキュリ ティリスクが高まる Slim Full OS主に Debian)から、実 行に必須ではないファイル (マ ニュアル、ドキュメント、一部の 不要なツール)を削除して軽量 化したもの Debian ベースで高い互換性を サポートしながらサイズは削減 されている。 シェルやパッケージマネー ジャーは含まれており、デバッ グがしやすい一方、攻撃対象領 域は小さくはない Alpine Alpine Linux という軽量なディ ストリビューションをベースにし たもの 標準 C ライブラリに glibc では なく軽量な musl を採用 軽量かつ攻撃対象領域が 小さいが、C 言語依存の ライブラリなどで互換性の 問題が出る可能性 シェルは軽量なものに置き換え られつつも、含まれている Distroless Google が提唱した、「アプリ ケーションとその実行の依存関 係のみ」を含んだイメージ Debian ベース) シェルやパッケージマネー ジャーなどが一切含まれていな いため、攻撃対象領域が 大幅に削減された軽量な イメージになる 一方で、デバッグのしずらさや、 マルチステージビルドが必須と なることが課題になる より少ないコンポーネント・小さいイメージサイズ
23. 発行元が明確なイメージ ≠ 依存関係・脆弱性が少ない その中でも様々なイメージの種類が提供され ており、その選択次第で依存関係・脆弱性の 総数が異なる 必要最小限のコンポーネント ≠ 脆 弱性対応が速い 潜在的な脆弱性の総数は減らせるものの、 発生した脆弱性に対する修正は以前としてコ ミュニティによるボランティアベース Distroless はイメージの 種類が少ない 主要な言語ランタイム Java, Python, Node.js, Go, Rust など)のみで、 Postgres, Redis, Nginx などのイメージは 提供されていない 組織・チームとして選択すべきイメージが複雑になりがち 統制が効かなくなってしまう イメージ選定における課題
24. Hardened Container Images 依存関係・脆弱性を根本から大幅に削減Near Zero CVEs)し、脆弱性が検知されると 即座にパッチ適用を行うSLA保証) Chainguard Containers ソフトウェアサプライチェーンセキュリティに特化した Chainguard 社が 2022 年から提供を開始した Hardened Container Images コンテナ専用に設計された OS「Wolfi」を採用し、不要な パッケージが極限に削減されている ➔ 2000 以上のイメージを提供 ➔ CVE に対する SLA 保証 ➔ 最大 6 ヶ月の EOL Grace Period(猶予期間) を提供 Docker Hardened Images Enterprise Docker 社が 2025 年から提供を開始した Hardened Container Images 既存の Linux ディストリビューション Alpine / Debian)と高い互換性 を持っており、Dockerfile に大きな変更をすることが なく、依存関係や脆弱性を大幅に削減 ➔ 1000 以上のイメージを提供 ➔ CVE に対する SLA 保証 ➔ オプションで、最大 5 年間の Extended Lifecycle Support を提供
25. ベースイメージに含まれる脆弱性を 24 時間以内に修正 Golang プロジェクトで広く使われている golang.org/x/crypto/ssh に影響を与える3つの脆弱性 (CVE-2025-47913, CVE-2025-47914, CVE-2025-58181) Docker Hardened Images Enterprise は 24 時間以内に パッチ修正版をリリース • バッチスケジュールではなく、 CVE が発表されたら 即時にアドバイザリーデータベースに 取り込み、モニタリング • SBOM を参照し、影響のあるイメージを即時 評価 • 自動的にセキュリティパッチワークフローを 実施し、修正版イメージを配布 https://www.docker.com/ja-jp/blog/how-docker-hardened-images-patch-cves-in-24-hours/
26. Critical CVE を上流から修正 Node.js のライブラリ expr-eval でリモートコード実行の脆弱 性が発覚(CVE Score 9.8) • Kibana プロジェクトに影響 • Docker(Scout) アドバイザリーデータベースが 依存関係を把握 • AI エージェントフレームワークで有名な LangChain.js が expr-eval を利用 • Docker Security チームが、代替ライブラリである math-expression-evaluator に変更する Pull Request を作成 • すばやくそれらの変更を Docker Hardened Images Enterprise に反映 https://www.docker.com/ja-jp/blog/security-that- strengthens-the-ecosystem-dockers-upstream-a pproach-to-cve-2025-12735/
27. 無償・オープンソースで提供 CVEs がほぼゼロのイメージを 1000 以上提供 シェルやパッケージマネージャーを含めない攻撃対象領域を 大幅に削減した distroless ランタイムイメージも提供 既存の Linux ディストリビューション Debian, Alpine) との高い互換性、簡単な移行を実現 Apache 2.0 の完全なオープンソース SBOM, Provenance, CVE 情報の完全公開 SLSA Build Level 3 の実現
28. 無償版 Hardened Container Images 比較 2026年4月時点) Distroless Chainguard Containers Docker Hardened Images Community 利用できるイメージの種類 主要な言語ランタイムJava, Python, Node.js, Go, Rust など)のみ 「Developer Images」 として約50種類の主要 イメージを利用可能 latest のみ 言語ランタイムだけでなく Postgres, Redis, Nginx 含め 1000 以上 複数バージョンを提供 Linux ディストリビューション Debian(glibc) ベース 独自OS「Wolfi」 Debian(glibc)ベースと Alpine(musl)ベース SBOM や CVE 情報の提供 CVE修正に対する SLA 保証
29. Hardened Container Images への移行方法 (デモ)
30. まとめ
31. まとめ • コンテナイメージには多くの OSS の依存関係が含まれており、その脆弱性を狙ったソフト ウェアサプライチェーン攻撃が急増・深刻化 • スキャン・アラートツールのみを導入しても、大量の脆弱性に対して対応コストが増加してし まう・対応を放置してしまう • 特にベースイメージに含まれる不要な依存関係(シェルやパッケージマネージャー)によっ て潜在的な脆弱性の総数が増えがち • また、ベースイメージの脆弱性対応は開発者コミュニティによるボランティア ベースになりがち • Hardened Container Images ◦ 信頼された発行元から提供 ◦ Distroless の思想に基づき、アプリケーション実行に不要な依存関係・ 攻撃対象領域を大幅に削減 ◦ 既知の CVEs をほぼゼロ、追加で迅速な脆弱性パッチ・SLA保証のサポートを受け ることが可能
32. Thank you!! tadashi.nemoto@docker.com