Dockerと考えるソフトウェアサプライチェーンセキュリティ 〜ビジネスアジリティと安全を両立する、持続可能なコンテナ開発の進め方〜

Docker と考えるソフトウェアサプライチェーン セキュリティ ビジネスアジリティと安全を両立する、持続可能なコンテナ開発の進め方 Security Days 2026 Spring Tadashi Nemoto Strategic Solutions Engineer, Docker

自己紹介 複数の日系企業でテスト自動化エンジニア ・DevOps エンジニアとして活動した後、 プリセールスエンジニアとして DevSecOps、 CI/CD、自動テストを中心にお客様の技術支援や 情報発信を行ってきました。2024 年 8 月に日本 拠点 1 人目のプリセールスエンジニアと tadashi0713.dev して Docker に入社。 tadashi-nemoto tadashi0713-dev

このセッションの概要 2013年に Docker が広めたコンテナ技術は、その開発・運用のしやすさから クラウドネイティブ開発の標準となりました。一方で、多数の OSS で構成 される「コンテナイメージ」は、脆弱性を狙ったサプライチェーン攻撃の標的となりつつ あります。本講演では、コンテナ技術の基礎からリスクの構造までを分かりやすく紐解 きます。その上で、SBOM による可視化や信頼できるベースイメージの選定などを通 じ、開発者とセキュリティ担当者が連携してビジネスアジリティと安全性を両立させる 「DevSecOps」の実践的な仕組み作りに ついてご紹介します。

アジェンダ ● Docker とコンテナ技術 ● コンテナイメージとソフトウェア サプライチェーンセキュリティ ● コンテナイメージを分析し、 脆弱性を修正・検知する ● 安全なベースイメージを選択する ● まとめ

Docker とコンテナ技術

Docker 社の歴史 2010 2015 現在 Open Container Initiative 設立 Unlock Developer Creativity 2013 dotCloud 設立 Docker Inc. 設立 開発者 がアプリケーションの dotCloud 時代にオープンソース デプロイ ・管理を簡単にする として発表したコンテナ型仮想 コンテナ技術のオープンな業界 PaaS 型クラウドを提供 化ソフトウェア「 Docker」が急速 標準 に注目され、ビジネス (image・runtime・distribution)を モデルと社名を変更 策定するために Docker が設立 後に Linux Foundation 傘下に Docker Desktop や Docker Hub など のコンテナ開発ツール・エコシステム の強化を行うほか、コンテナアプリ ケーションにおけるサプライチェーン セキュリティ強化・ AIエージェント開発 支援など、より開発者が安全・高速な 開発ができるようなソリューションを提 供

VM とコンテナの違い App 1 App 2 App 3 Bins/Libs Bins/Libs Bins/Libs Guest OS Guest OS Guest OS Hypervisor App 1 App 2 App 3 Bins/Libs Bins/Libs Bins/Libs Host operating system Operating system Physical hardware Physical hardware ➔ OS 全体を動かす ➔ アプリケーションと依存関係のみ動かす ➔ サイズが大きいUbuntu 23.10 2.6GB) ➔ サイズが小さいUbuntu 23.10 129MB) ➔ 起動が遅い(数分) ➔ 起動が早い(数秒) Container engine

コンテナ “イメージ” を作る OS パッケージ アプリケーション ランタイム 検証環境 コンテナイメージ アプリケーション 依存関係 アプリケーション コード コンテナレジストリ 本番環境

Build once. Run anywhere. ➔ 一度イメージを作ってしまえば、そのコンテナは他の開発環境や本番環境・検証環境 でも同様に動作する ➔ 変更したい場合には、新しくイメージを作成して置き換える ➔ 高い再現性を実現することが可能 コンテナレジストリ(Docker Hub) 開発環境 1 開発環境 2 CI/CD パイプライン 本番環境・検証環境

Docker Hub にあるイメージを動かす(PostgreSQL) CLI $ docker run -e POSTGRES_PASSWORD=dev \ -p 5432:5432 postgres:17.1 $ psql -h localhost -U postgres

Docker コンテナを使用する利点 アプリケーションと アプリケーションの 軽量で 高い隔離性と 依存関係の ポータビリティ リソース効率が高い 再現性 パッケージ化

#1 最も人気のある開発者ツール 95% 2400万 以上 Docker Hub ユーザー数 1400万 以上 Docker Hub にあるコンテナイメージ数 Gartner の調査によると、 2029年までに95%以上の企業が 200億 以上 コンテナ化されたアプリケーションを本 Docker Hub の月間ダウンロード数 *2025 Stack Overflow Developer Survey 番環境で実行すると予測

コンテナイメージとソフトウェア サプライチェーンセキュリティ

ソフトウェアサプライチェーンセキュリティ SOURCE THREATS Producer Source BUILD THREATS Build Dependencies DEPENDENCY THREATS Package Consumer

Dockerfile FROM node:20-alpine OSAlpine Linux)とランタイム Node.js)、それに必要な依存関係がイ ンストールされたベースイメージを利用 WORKDIR /app RUN apk add --no-cache curl 必要な OS パッケージを個別に インストール COPY . . RUN npm install --production EXPOSE 3000 CMD ["npm", "start"] アプリケーションの依存パッケージ (npm, pip, Maven, RubyGem など) をインストール

ソフトウェアサプライチェーン攻撃 コンテナイメージには、多くの OSS の依存関係を含む ことになり、その依存関係の中に(意図的にインストー ルしていなくても)脆弱性が含まれている場合、自分た ちのコンテナイメージにも影響を受ける 1つのパッケージを改ざん・脆弱性を悪用するだけで、(意 図的にインストールしていないものも含め)多くのアプリ ケーションに悪影響を与えることが できる https://anchore.com/software-supply-chain-security/what-is-sscs/

• https://anchore.com/software-supply-chain-security/what-is-sscs/

脆弱性(CVEs)の急増とサプライチェーン攻撃の深刻化

Log4j(CVE-2021-44228, Log4jShell) 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大手や自動 車大手、金融機関などとの取引情報が含まれるという。 https://xtech.nikkei.com/atcl/nxt/column/18/00001/06457/

• https://xtech.nikkei.com/atcl/nxt/column/18/00001/06457/

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

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/

• https://xenospectrum.com/mongobleed-cve-2025-14847-mongodb-exploit-ubisoft-breach/

利用者の慢心 Complacency)による リスクの放置・拡大 99.5% 80% 以上 13% 修正版が提供された OSS コンポーネント アプリケーション 依存関係が1年以上 アップデートされて いない Log4Shell 公開から3年 以上経過した後にも、 影響のあるバージョンがダ ウンロード 適切に対応できていれば、 ほとんどのリスクは防げたも の sonatype: 10th Annual State of the Software Supply Chain

コンテナアプリケーションを安全にする対策 コンテナイメージを分析し、 安全なベースイメージを 脆弱性を修正・検知する 選択する コンテナ技術を最大限活用した、 素早いパッチの本番環境への適用 (DevSecOps)

コンテナイメージを分析し、 脆弱性を修正・検知する

SBOM(Software Bill of Materials) 経済産業省: ソフトウェア管理に向けた SBOM（Software Bill of Materials）の導入に関する手引

SBOM とコンテナイメージスキャン 開発者 コンテナイメージ をビルド アドバイザリー データベース ポリシー評価 コンテナイメージから SBOM を生成 脆弱性CVE含めた 分析結果 フィードバック コンテナイメージから SBOM を生成 アドバイザリーデータベース ポリシー評価 Syft, Trivy, Docker SBOM Syft ベース)などが存在する 公的な情報から、Linux ディストリビュー ション、アプリケーションが 依存するパッケージマネージャーなどの 脆弱性情報を集約・整理したデータベー ス 生成した SBOM や検出された脆弱性 CVE情報に対して、デプロイできるため の組織の基準に満たしているのか判断す るためのゲートキーパーの役割 SPDX や CycloneDX といった主要 フォーマットに出力が可能

コンテナイメージスキャン ローカル開発環境での分析 CI/CD パイプラインでの分析 コンテナレジストリでの分析 手元でビルドしたコンテナイメージを 分析し、修正可能な脆弱性を対応する パイプラインでコンテナイメージを ビルドした上で分析を行う あるいは、新しく追加した依存関係に 脆弱性がないか確認する 脆弱性情報や組織のポリシーを満たしてい るのか開発者にフィーバック レポジトリに新しく追加されたコンテナイメー ジに対して分析を行い、レポジトリ・レジストリ をまたいだ横断的な可視化・ポリシーの策定 を行う。

コンテナイメージスキャン選定基準 豊富かつ最新の リアルタイムに検知 開発者が検知・修正 あらゆるフェーズで データベース することができるか しやすいか 検知ができるか 公的な情報だけでなく、Linux ディストリビューションが独自で 公開している セキュアアドバイザリーや、アプ リケーションが依存するライブラ リに対応した、広範かつ最新の データベース スキャン時点では「安全」と判定 されたイメージも、時間の経過と ともに「脆弱」な 状態へと変化する 単に脆弱性の ID やリスクレベ ルを羅列するだけでなく、「どの バージョンにアップグレードされ れば解消されるか」という明確 な修正案 あらゆるフェーズで検知を 行う多層防御の考え方が必要 CVE が公開されたと同時に再 評価し、影響のある イメージを特定 日常の開発の中で無理なく 修正活動を行える環境 開発者のローカル環境、CI/CD パイプライン、 コンテナレジストリで一貫 したポリシーとスキャン エンジンを適用

主なコンテナイメージスキャンツール Trivy Docker Scout 元々日本の個人開発者(福田哲 平氏)が開発したオープンソース ツールを Aqua Security 社に 買収・譲渡 された Docker 社が提供する コンテナイメージ分析 ソリューション CLI で主にローカル開発環境や CI/CD パイプラインで 手軽に利用することができる 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 との統合によっ て、ビルド内容と本番 環境での実行結果を比較するこ とが可能

素早く本番環境に取り込む仕組み(DevSecOps) コンテナ技術を導入する恩恵を最大限活かす 継続的インテグレーション 自動化されたビルド・テストによって、アプリケーショ ンの動作に影響が出ないことを確認 継続的デリバリー 自動化されたデプロイ、段階的リリースに よって効率的・安全なリリースを実現 継続的モニタリング リリース後に本番環境に影響があるか、 脆弱性は解消されたのか確認

安全なベースイメージを選択する

Dockerfile FROM node:20-alpine WORKDIR /app RUN apk add --no-cache curl COPY . . RUN npm install --production EXPOSE 3000 CMD ["npm", "start"] ➔ ベースイメージにも多くの依存関係 と脆弱性が含まれている ➔ 開発者が容易に修正することが できない ➔ 一般的にはコミュニティが作成・ メンテナンスしている ➔ 脆弱性への対応がコミュニティの 努力次第 ➔ 発行元が不明確だと、マルウェアの 混入やバックドアが仕掛けられる 可能性も

Docker Hub にあるイメージを動かす(PostgreSQL) CLI $ docker run -e POSTGRES_PASSWORD=dev \ -p 5432:5432 postgres:17.1 $ psql -h localhost -U postgres サードパーティーのイメージを本番環境などで動かした場合にも、 この依存関係・脆弱性・修正の難しさの問題は残り続ける

安全なベースイメージを選択する方法 信頼できるパブリッシャーから 必要最小限のコンポーネントで 脆弱性の少ない・迅速な対応を イメージを選択する 構成されたイメージを選択する するイメージを選択する 発行元が不明確なイメージを排除する ことによって、公式を装った悪意のあるイメー ジ(タイポスワッピング)や マルウェアの混入・バックドアが仕掛けられ たイメージを未然に防ぐ 汎用的な OS イメージFull OSには アプリケーションの実行自体には不要なパッ ケージ(シェル、コンパイラ、 パッケージマネージャー等)が含まれており、 それらを削減したイメージを利用することで、 攻撃対象領域や潜在的な 脆弱性の総数を削減できる Hardened Container Image) コミュニティによるボランティアベースの脆弱 性対応ではなく、「Zero CVE」を目標に掲 げ、脆弱性対応の SLA が 保証されているイメージによって、 コンプライアンス遵守とセキュリティ リスクの最小化を実現

Docker Hub で信頼されたイメージを利用する Docker Official Image Docker Verified Docker Sponsored Publisher Image OSS Image アップストリームメンテナ(開発 Docker とパートナーシップを結 世界中で広く利用されている などによって提供される 元が)共同でメンテナンスしてい んだ企業(ベンダー)が OSS プロジェクトに対し、 イメージ るイメージ 提供し、その身元が証明されて Docker がスポンサーとして支 メンテナンスが放置されて 定期的な脆弱性スキャンも いるイメージ 援しているイメージ いるものや、セキュリティ上 Docker の専任チームと 実施 Community Image コミュニティや個人開発者 問題があるものも混在

Docker Official Image は Docker Scout に よる脆弱性スキャンが実行・公開 事前に脆弱性を把握することが可能

必要最小限のコンポーネントで構成されたイメージを選択 Full OS Debian, Ubuntu) 標準的な Linux ディストリ ビューションをそのまま コンテナイメージ化したもの 高い互換性を持っており、 一般的な Linux 環境に含まれ る多くのツールが含まれている ため、トラブルシューティングが 容易 一方でサイズも大きく、含まれる パッケージも多いため、セキュリ ティリスクが高まる Slim Alpine Distroless Full OS主に Debian)から、実 行に必須ではないファイル(マ ニュアル、ドキュメント、一部の 不要なツール)を削除して軽量 化したもの Alpine Linux という軽量なディ ストリビューションをベースにし たもの Google が提唱した、 「アプリケーションとその 実行の依存関係のみ」を 含んだイメージ Debian ベースで高い互換性を サポートしながらサイズは削減 されている。 シェルやパッケージマネー ジャーは含まれており、デバッ グがしやすい一方、攻撃対象領 域は小さくはない 標準 C ライブラリに glibc では なく軽量な musl を採用 軽量かつ攻撃対象領域が 小さいが、C 言語依存の ライブラリなどで互換性の 問題が出る可能性 シェルは軽量なものに置き換え られつつも、含まれている より少ないコンポーネント・小さいイメージサイズ シェルやパッケージマネー ジャーなどが一切含まれていな いため、攻撃対象領域が 大幅に削減された軽量な イメージになる 一方で、デバッグのしずらさや、 マルチステージビルドが必須と なることが課題になる

Hardened Container Images 依存関係・脆弱性を根本から大幅に削減Near Zero CVEs)し、脆弱性が検知されると 即座にパッチ適用を行うSLA保証) Chainguard Containers Docker Hardened Images Enterprise ソフトウェアサプライチェーンセキュリティに特化したChainguard 社が 2022 年から提供を開始した Hardened Container Images Docker 社が 2025 年から提供を開始した Hardened Container Images コンテナ専用に設計されたOS「Wolfi」を採用し、不要な パッケージが極限に削減されている ➔ ➔ ➔ 2000 以上のイメージを提供 CVE に対する SLA 保証 最大 6 ヶ月の EOL Grace Period(猶予期間) を提供 既存の Linux ディストリビューションAlpine / Debian)と高い互換性 を持っており、Dockerfile に大きな変更をすることが なく、依存関係や脆弱性を大幅に削減 ➔ ➔ ➔ 1000 以上のイメージを提供 CVE に対する SLA 保証 オプションで、最大 5 年間の Extended Lifecycle Support を提供

ベースイメージに含まれる脆弱性を 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/

• https://www.docker.com/ja-jp/blog/how-docker-hardened-images-patch-cves-in-24-hours/

無償・オープンソースで提供 CVEs がほぼゼロのイメージを 1000 以上提供 シェルやパッケージマネージャーを含めない攻撃対象領域を 大幅に削減した distroless ランタイムイメージも提供 既存の Linux ディストリビューション Debian, Alpine) との高い互換性、簡単な移行を実現 SBOM, Provenance, CVE 情報の完全公開 SLSA Build Level 3 の実現 Apache 2.0 の完全なオープンソース

素早く本番環境に取り込む仕組み(DevSecOps) コンテナ技術を導入する恩恵を最大限活かす 継続的インテグレーション 自動化されたビルド・テストによって、アプリケーショ ンの動作に影響が出ないことを確認 継続的デリバリー 自動化されたデプロイ、段階的リリースに よって効率的・安全なリリースを実現 継続的モニタリング リリース後に本番環境に影響があるか、 脆弱性は解消されたのか確認

まとめ

まとめ ● コンテナ技術はその開発・運用のしやすさから、多くの開発者に人気のある、 本番環境で急速に普及していく技術 ● コンテナイメージには多くのオープンソースソフトウェアの依存関係が含まれて おり、その脆弱性を狙ったソフトウェアサプライチェーン攻撃が急増・深刻化 ● 対策 1: コンテナイメージを分析し、脆弱性を修正・検知する ○ ● ● コンテナイメージから SBOM を生成・スキャンツールと組み合わせることで、あらゆ るフェーズでリアルタイムに分析・検知・修正 対策 2: 安全なベースイメージを選択する ○ 信頼できるパブリッシャーからイメージを選択する ○ 必要最小限のコンポーネントで構成されたイメージを選択する ○ Hardened Container Images 対策 3: コンテナ技術を最大限に活用し、脆弱性パッチやベースイメージ更新に 対して、素早く本番環境に取り込む仕組み(DevSecOps)

Thank you!! [email protected]