Docker、開発終了した「MinIO」の延長サポートを開始　最大5年間のセキュリティパッチ提供と監査対応を支援

要点

• オープンソースのオブジェクトストレージ「MinIO」が2026年2月に開発終了したことを受け、Docker社が延長サポートの提供を開始した。

• 「Docker ELS」の対象にMinIOが加わり、開発終了後も最大5年間にわたりセキュリティパッチの適用とイメージの保守が行われる。

• 緊急および高重要度の脆弱性に対して14日以内の修正SLAが設定され、Go言語の推移的依存関係を含む脆弱性も追跡・修正される。

• SBOMやVEX、SLSA Level 3といった監査証跡が標準で添付され、Dockerfileの記述を変更するだけで既存環境のまま導入できる。

• 米Dockerは2026年8月24日、オープンソースのオブジェクトストレージ「MinIO」を対象とした延長サポート「Docker Extended Lifecycle Support（ELS）」の提供を開始したと公式ブログで発表した。MinIOは2026年2月に開発元によってアーカイブ化されており、本サポートによって利用企業は最大5年間にわたりセキュリティ修正とコンプライアンス監査への適合を維持できるようになるという。

突然の開発終了とストレージ基盤が抱えるリスク

2026年2月13日、オープンソースのオブジェクトストレージ（データをファイル単位ではなくオブジェクト単位で管理する方式）として広く普及していたMinIOプロジェクトが、アップストリーム（開発元リポジトリ）においてアーカイブされた。同プロジェクトはDocker Hub上で累計10億回以上のダウンロード数を記録していたが、このアーカイブ化により、新規リリースや不具合修正、セキュリティパッチの提供が突如として停止する事態となった。

これにより、稼働中のMinIO環境およびそれが依存するGo言語のライブラリ群に新たなCVE（共通脆弱性識別子）が発見された場合でも、開発元からの修正版は提供されない状態が続いている。特にストレージ基盤は扱うデータ量がペタバイト（1ペタバイトは1000テラバイト）規模に達することも珍しくなく、他システムへの移行には多大な時間とコストを要する。移行作業が長期化する間も脆弱性に晒され続けるため、運用チームは「商用製品への移行によるベンダーロックイン」「自社でのセキュリティパッチ開発」「外部ベンダーによる延長サポートの利用」という限られた選択肢を迫られていた。

業界全体に広がるEOL問題と規制監査の壁

MinIOの事例は特殊な例外ではなく、オープンソースソフトウェア全体で深刻化している課題の一端にすぎない。セキュリティ企業Black Duckの「2026 Open Source Security and Risk Analysis（OSSRA）」レポートによれば、商用コードベースの93%に少なくとも2年以上開発活動が行われていないコンポーネントが含まれているという。Node.js 18やPython 3.8、旧バージョンのApache Airflowなど、公式サポートが終了（EOL）したソフトウェアが本番環境で稼働し続けているケースは依然として多い。

さらに近年では、米国のFedRAMP（クラウドのセキュリティ評価・認証制度）や欧州のDORA（金融セクター向けデジタル運用レジリエンス法）、EUサイバーレジリエンス法（デジタル製品のセキュリティ基準を定める法律）といった規制枠組みが強化されている。これらの監査基準では、未修正のEOLソフトウェアが運用されていること自体が重大な指摘事項となるため、システム開発の計画ではなく監査の期日に追われて無理な移行を強いられるリスクが生じている。

「Docker ELS」の仕組みとMinIO向けサポート内容

Docker社が提供する「Docker ELS」は、セキュリティ強化済みコンテナイメージ群「Docker Hardened Images（DHI）」の有償アドオンとして展開されるサービスである。アップストリームの開発が終了したソフトウェアについて、Docker社が独自にソースコードからビルドと保守を引き継ぎ、EOL後最大5年間にわたってパッチ適用済みイメージを提供する。

今回カタログに追加されたMinIO向けELSイメージでは、MinIO本体だけでなく、依存関係にあるGo言語のパッケージツリー全体（直接依存していない推移的依存関係を含む）の脆弱性が追跡される。重大度が「緊急（Critical）」および「高（High）」に分類されるCVEに対しては、14日以内のSLA（サービス品質保証）に基づき、修正パッチのバックポート（旧バージョンへの修正適用）とイメージの再ビルドが追加費用なしで実施される仕組みとなっている。

また、導入にあたって大規模なシステム改修は不要とされている。ELSイメージは通常のDHIカタログ内に専用タグ付きで配信されるため、開発者はDockerfile内のベースイメージ指定（FROM行）を変更するだけで利用を開始できる。

監査に対応するセキュリティ証跡の標準添付

Docker ELSの大きな特徴として、コンプライアンス監査に必要な各種証明データの同梱が挙げられる。提供されるすべてのイメージはソースからビルドされて電子署名が施されているほか、ソフトウェア部品表であるSBOM（Software Bill of Materials）、脆弱性の影響有無を示すVEX（Vulnerability Exploitability eXchange）情報、そしてサプライチェーンセキュリティ規格である「SLSA Build Level 3」に準拠した来歴情報が維持される。

脆弱性スキャナーによる機械的な警告だけでなく、どの脆弱性が修正済みでどれが悪用不可能であるかの署名付き証跡が提示されるため、監査への対応が容易になるという。さらに、ライセンスは特定のリポジトリ単位で適用可能であり、あるシステムの移行が完了した際には別のリポジトリへ割り当てを変更して継続利用できる設計となっている。同社はカタログに未掲載のEOLソフトウェアについても個別リクエストを受け付けており、すでにNginxやNode.js、PythonなどのELSイメージを提供していると説明している。