サプライチェーンへの攻撃は、ここ1年ほどの間に、もはや単発的な事件ではなくなってきた。こうした妥協は、業界が自衛のために信頼しているツールにまで及んでおり、今年はTrivyやKICSなどが標的となっている。Dockerの最高情報セキュリティ責任者であるマーク・レヒナー氏は、今回の攻撃の波を「脅威の状況における恒久的な変化」と呼び、その後の数ヶ月でそれが裏付けられた。取引量も同時に増加している。現在、本番環境で使用されるコードの4分の1以上がAIによって作成されており、エージェントは機械の速度で依存関係を取り込んでいる。プラットフォームチームやセキュリティプログラムを運営しているなら、これは既にあなたが直面している状況です。毎週、より多くのコードとイメージが届きますが、そのほとんどは自社のエンジニアが書いたものではなく、出荷された瞬間からすべてがあなたの責任となります。
これは私たちにとって目新しい情報ではない。ソフトウェアサプライチェーンのセキュリティ確保こそ、私たちが解決しようとしている課題です。今回の最新アップデートにより、Dockerがお客様のサプライチェーンの基盤として構築している信頼性の高いシステムはさらに強化され、その運用方法もより厳格化されます。イメージに含まれるソフトウェアの多くは、Docker自身によって構築およびパッチ適用されるようになり、ソフトウェアのサポート終了後もセキュリティ対策が継続されます。イメージは保証を損なうことなく環境に合わせてカスタマイズでき、ポリシーの適用範囲はすべての開発者マシンに及ぶようになりました。
サプライチェーン全体を支える信頼できる基盤
すべては一つの原則から始まり、Docker Hardened Imagesはその原則に基づいて構築された。採用されないセキュリティ対策は、何も守らない。カタログ全体はすべての開発者に無料で提供されます。なぜなら、安全なベースラインはプレミアム機能であるべきではないからです。すべてのイメージは、チームが既に利用しているディストリビューションであるAlpineとDebianと互換性があり、Dockerはそれらすべてをソースコードから独自に構築します。導入とは、移行プロジェクトではなく、既存システムの変更を指します。また、すべてのイメージは署名済みのSBOM（ソフトウェア部品表）とSLSAビルドレベル3の来歴情報によって独立して検証可能であるため、監査担当者はベンダーの主張ではなく証拠に基づいて作業を行うことができます。
1年が経過し、数字がその正しさを証明している。カタログは4 、 000強化イメージに加え、MCPサーバー、Helmチャート、ELSイメージへと拡大しました。週に3 5回以上プルされ、100万回以上のビルドが定期的に実行されてすべてにパッチが適用され、 8のようなオープンソースプロジェクトがDHI上で本番運用を行っています。カタログはこれまでと同様に、顧客からの要望に基づいて拡大していく。しかし、目標は単なるカタログを作ることではなかった。目標は、ソフトウェアサプライチェーン全体を支える信頼できる基盤を構築することです。つまり、実行するイメージ、その中のパッケージ、それらを展開するチャート、そしてエージェントが呼び出すツールすべてが、同じ出所を持つようにすることです。セキュリティは初日からデフォルト設定となり、チームの働き方を変えることなく維持されます。
ソースコードから構築され、すべてのパッケージに至るまで、
硬化はスタックのより深い層へと広がっていく。Docker Hardened System Packagesは、AlpineとDebianの両方において、イメージの下、つまりイメージ内のパッケージにまでセキュリティ強化を施し、すべてのパッケージがアップストリームソースからビルドされ、パッチが適用され、イメージ自体をビルドするのと同じSLSAビルドレベル3パイプラインでDockerによって維持されます。そして、それらの背後にあるリポジトリは、カタログ以上のものにも公開されている。DHI Enterpriseのお客様は、aptまたはapkを直接Dockerの強化されたパッケージリポジトリに指定し、同じパッケージを自社で構築するイメージに取り込むことができます。これにより、強化されたサプライチェーンをDockerが提供するイメージだけでなく、組織が構築するすべてのイメージにまで拡張できます。
報道範囲は拡大し続けている。Alpineから始まったこの取り組みは、現在ではDebianにも広がり、カタログで最も多くダウンロードされているイメージであるPythonは、完全にセキュリティ強化された状態で出荷される最初のイメージの一つとなっている。作業は毎週積み重なり、 DebianとAlpineのパッケージリストは公開されているため、カタログがリアルタイムで強化されていく様子を確認できます。
ベースイメージのCVEを追跡した経験がある方なら、これがなぜ重要なのかお分かりでしょう。システムパッケージは修正が遅いことで悪名高く、パッチが次のディストリビューションのリリースまで何ヶ月、何年も放置されることがある。Dockerは待機しません。重要な局面では、パッケージレベルでパッチを適用し、上流よりも先に修正を適用します。そして、その修正は、イメージごとにではなく、1回のビルドで、そのパッケージを使用するすべてのイメージに適用されます。コミュニティよりも早くコミュニティ向けセキュリティアップデートを提供することを基盤としたビジネスが数多く存在する。DHIなら、その速度は標準装備です。
保証内容は、検証後も有効であることが証明された。DHIのカスタマイズを通じて追加するパッケージ（ワークロードに合わせてイメージを調整するパッケージ）は、検証されていない公開ミラーではなく、同じ強化されたリポジトリから取得されるため、それ自体が強化されたシステムパッケージであり、ベースイメージを対象とするSLAは、追加するすべてのパッケージに適用されます。また、イメージ、その中のパッケージ、CVE調査、パッチのすべてを1つのベンダーが保証するため、監査担当者は複数のベンダーからの保証書ではなく、署名済みの単一の出所証明を得ることができます。
一方、あなたの分配方法は、あなたの分配方法のままです。ソースコードから堅牢なパッケージエコシステムを構築することは、高度なエンジニアリングを要する作業であり、DockerはAlpineとDebianの2つのプラットフォームでそれを実現しました。そのため、自社の標準規格を維持することで、セキュリティ体制を損なうことは決してありません。
サポート終了後のパッチ
実稼働中のソフトウェアは、保守担当者の寿命よりも長く存続する傾向がある。移行作業は予算、依存関係、テストサイクルを待つ必要があるが、CVE（共通脆弱性識別子）はそれらを待ってくれない。DHIの拡張ライフサイクルサポート（ELS）は、まさにそうした問題を解決するために存在するのです。これにより、サポート終了となったソフトウェアにパッチを適用し、SBOM（ソフトウェア部品表）と来歴情報を維持したまま、最長5年間ソフトウェアを保護できます。
ELSは、特定のカタログに限定されるわけでもありません。Dockerはサポート終了カレンダーを監視し、それ以前にサポート体制を構築しています。また、表示されていないサポートについてはリクエストすることができます。MinIOは最新の追加機能です。2026アップストリームは2月にプロジェクトをアーカイブしましたが、DHIカタログにはパッチが適用され強化された状態で残っており、移行はアップストリームのスケジュールではなく、お客様のスケジュールで実行されます。
大規模なカスタマイズ、コードとしての管理
誰も制作現場でストック画像を使うことはない。CA証明書、エージェント、およびアプリケーションが必要とするパッケージを追加します。問題は、この市場のほとんどにおいて、最初の変更が販売者の保証の限界であり、それ以降の費用はすべて購入者が負担しなければならないということだ。DHIのカスタマイズは、その逆の仕組みで行われます。イメージに必要な要素を定義するだけで、Dockerはカスタマイズされたイメージのライフサイクル全体を管理し、アップストリームのパッチが適用されるたびに、同じ強化されたパイプラインを通じてイメージを再構築します。SBOM、証明書、およびSLAは、カスタマイズによって消滅するのではなく、カスタマイズと共に移行されます。
カスタマイズは大規模にも適用されます。UI、CLI、APIを通じて一括カスタマイズを実行でき、YAML設定とGitHub Actionsのサポートも備えているため、一度に数百のリポジトリをカスタマイズして、再構築は自動的に処理されます。プラットフォームがTerraformで動作している場合、カスタマイズもコードで行います。DHI Terraformプロバイダーは、お客様のインフラストラクチャの他の部分と同様のプルリクエストとレビューを使用して、強化されたイメージをミラーリングおよびカスタマイズします。
その節約は、誤差の範囲ではなく、真のインフラ整備に関わるものです。お客様からは、イメージの再構築のためだけに存在していたCIパイプラインを停止したという声が寄せられています。なぜなら、Dockerがイメージの再構築を自動的に行ってくれるようになったからです。盲目的な再デプロイのサイクルは、それらのパイプラインに付随するものです。修正が必要なときに、変更内容を正確に把握した上でアップデートをリリースする。スケジュール通りにすべてを再構築して、QAチームが変更点を見つけてくれることを期待するよりも効率的だ。
データ所在地の要件により画像をEU域内に保管する必要がある組織向けには、EU域内でホストされるカスタマイズ機能が9月に提供開始されます。カスタマイズされたイメージは、他の場所と同様に、同じSBOM、証明書、およびSLAとともに、Docker HubのEUリージョンに配置されます。研修医期間は、あなたの強化プログラムを遅らせる理由にはならなくなります。
基本イメージを超えて強化する
同じ基準が、次々と上位の段階へと移行していく。カタログには完全にサポートされたHelmチャートが掲載されているため、Kubernetesのデプロイメントも最初から強化された状態で開始できます。また、強化されたMCPサーバーの数も増え続けています。なぜなら、エージェントが呼び出すツールは、それらが動作するイメージと同様に、厳密な検証を受けるに値するからです。
Docker Scoutポリシーで全てを管理
スキャンすれば、何が問題なのかが分かります。ポリシーとは、それが出荷されないようにするための方法です。そして、ほとんどのサプライチェーンプログラムがひっそりと失敗するのは、その実施段階においてです。なぜなら、強化された対策は、チームが実際にそれを使用した場合にのみ効果を発揮するからです。開発者は迅速に行動し、うまく機能するものを優先する傾向があるため、開発者のマシンこそが、現在の攻撃の標的となっている。
Docker Scoutのポリシーは、そのギャップを埋めます。CLIおよびCI内部から柔軟でカスタマイズ可能なポリシーを評価し、Dockerがカタログ内のすべての強化済みイメージを検証するために使用するポリシーと同じポリシーを同梱しています。これらのポリシーは業界標準であるRegoで記述されており、移植性も高いため、CI環境でビルドをゲートする同じルールが、チームとともに組織内のすべての開発者マシンに展開されます。レジストリでのアクセス制限は重要だが、それはレジストリで止まる。開発者はいくらでもそれを回避できる。マシンに適用されるポリシーとは、実行するすべてのイメージ、そしてチームが構築するすべてのイメージを、Docker自身が課している基準に適合させる方法です。
これは添加剤による制御です。これは、既に実行しているスキャナーと連携して動作し、既に利用しているDockerサブスクリプションに含まれています。
基盤は既にスタックに含まれています
サプライチェーンの問題は縮小することはないだろう。今後さらに多くのコードが追加され、エージェントが貢献者になりつつあり、規制当局が求めるパッチ適用期間はますます短くなっている。先端工具ではその重量を支えることはできません。デフォルトで安全な基盤は、それを維持するエコシステムに支えられていれば、今後も安全であり続けるでしょう。まさにそれが、Dockerのセキュリティ製品群が提供するものです。既にご利用のディストリビューションにおける堅牢なコンテンツ、保証を維持するカスタマイズ、アップストリームよりも長く続くサポート、そしてお客様が管理できるポリシー。これらすべてを、責任を持つ単一のベンダーから提供します。
そして、そのどれもがあなたに何か新しいものを取り入れることを求めているわけではありません。それはすべて、あなたが既に実行しているDockerの中にあります。ビルド、ツール、パイプラインは変更されません。あなたのCVE数はそうではありません。
DHIのカタログを閲覧して、今日から最初の強化イメージをダウンロードしましょう。さらに、これらの仕組みの全体像を知りたい方、そして皆様からのご質問にライブでお答えするウェビナーにご参加いただける方は、9月上旬に開催されるライブウェビナーにご参加ください。ぜひ会場でお会いしましょう。
