本文へ移動
TechHiroba テックひろば
開発ツール AI生成 文責 blackstrawberry

MinIO の OSS リポジトリはアーカイブ済み、Docker ELS で残すなら確認すべき条件

MinIO の OSS リポジトリは GitHub 上でアーカイブされ読み取り専用になった。本番で MinIO を動かすチームの選択肢と、有料の Docker ELS が引き受ける範囲、記事に書かれていない条件を整理する。

  • docker
  • minio
  • security
  • eol
  • containers
目次
  1. 上流パッチが止まったまま本番にある、という状態
  2. Docker が並べた選択肢と、その並べ方
  3. ELS が引き受けると書かれている範囲
  4. 記事に載っていない条件
  5. MinIO を本番で動かしているなら
  6. 一次情報

MinIO のオープンソースリポジトリ（minio/minio）は GitHub 上でアーカイブされ、読み取り専用になっている。バナーの表記では 2026 年 4 月 25 日 のアーカイブだ。Docker のブログはこれを 2026 年 2 月 13 日と書いていて、日付は一致しない（後述）。どちらの日付を取るにせよ、アーカイブ以降は MinIO 本体と Go の依存ツリーに新しい CVE が出ても、上流からパッチは出ない。関係するのは、オブジェクトストレージとして MinIO を本番で動かし、別のシステムへ移し終えていないチームだ。動いているものが今日止まるわけではない。問題になるのは、次の CVE が出たときと、次の監査でサポート状況を問われたときだ。

上流パッチが止まったまま本番にある、という状態

Docker が 2026 年 8 月 24 日に公開した記事の主題は、自社の有料サービス Extended Lifecycle Support（ELS）の紹介だ。書き手は Docker でセキュリティ製品を担当する Principal Product Marketing Manager で、記事はそのつもりで読む必要がある。それでも、前提として置かれている事実は切り分けて拾える。

記事によれば、MinIO は Docker pull が 10 億回を超えるプロジェクトで、アーカイブによってリリース、バグ修正、セキュリティパッチが同時に止まった。新しい CVE は MinIO 本体だけでなく Go の依存関係からも来る。監査の側から見ると、パッチが出ない EOL ソフトウェアは、サポート外のものが本番にあるという指摘になる。記事は FedRAMP、DORA、Cyber Resilience Act の名を挙げ、これらの枠組みが未パッチの EOL ソフトウェアを監査指摘として扱うと書いている。移行の期限を決めるのはロードマップより監査カレンダーになる、というのが記事の言い分だ。

リポジトリの状態は GitHub で確かめられる。minio/minio はアーカイブ済みの読み取り専用で、バナーの日付は 2026 年 4 月 25 日だ。Docker の記事が書く 2 月 13 日が何を指すのかは、記事からは分からない。最終リリースの日付か、告知の日付か、単なる誤りか、MinIO 側の説明は見つかっていない。数字の出どころも切り分けておく。10 億回以上の pull は Docker の記事の記述だ。「商用コードベースの 93% が、2 年以上開発の止まったコンポーネントを含む」は Black Duck の 2026 年版 Open Source Security and Risk Analysis レポートにある数字で、同レポートは 17 業種・947 の商用コードベースの分析にもとづく。

Docker が並べた選択肢と、その並べ方

記事は MinIO を動かすチームの選択肢を三つに整理する。商用の代替製品へ移り、新しいライセンスとロックインを引き受ける。パッチを自前で当て続け、もう修正が出ないプロジェクトのために Go のセキュリティエンジニアリングを継続的に抱える。あるいは今動いているものをそのまま残し、ベンダーに責任を負わせる。何もしないことは四つ目の選択肢にならない、と記事は言い切る。

三番目がそのまま ELS だ。並べ方は当然 ELS に有利にできている。記事は、オブジェクトストアの移行はペタバイト単位で測る遅くて高い作業だと書き、その作業が走る間も CVE の露出は増え続けると続ける。移行の遅さと露出の継続は、規模を考えれば前提として無理がない。一方で、商用代替製品についてはロックインという一語で片づけられていて、比較の材料は出てこない。自前パッチの負担は、Go のセキュリティエンジニアリングを常時抱えることだと言い換えられているが、これも記事の主張であって数字はない。

ELS が引き受けると書かれている範囲

記事に書かれている ELS の条件を並べる。MinIO に固有の条件は書かれておらず、ELS 全般の説明として読む必要がある。

項目記事の記述
対象MinIO を含む EOL ソフトウェア。要望すれば Docker がビルドして保守する
期間上流の EOL から最長 5 年
パッチ SLACritical と High の CVE を 14 日以内
依存関係Go の依存グラフ全体。推移的依存も追加費用なし
添付される証跡ソースからビルドして署名。SBOM、VEX、SLSA Build Level 3 の provenance
提供形態DHI カタログに ELS タグとして掲載。同じレジストリ、FROM 行の変更で切り替え
料金Docker Hardened Images サブスクリプションの有料アドオン。金額の記載なし

出典：Docker ブログ、Vishrut Iyengar による MinIO ELS の記事（2026 年 8 月 24 日公開）

エンタイトルメントの単位はリポジトリだ。ひとつのリポジトリに適用すると、そこにある ELS バージョンすべてが対象になり、ひとつの移行が終わったら次のリポジトリへ付け替えられる、と記事は説明する。Nginx、Node、Python の ELS イメージはすでにカタログにあり、載っていないものは要望できるとも書かれている。Docker は EOL カレンダーを見て先回りでビルドする、という説明も添えられている。

VEX の同梱は、この記事が監査対応の文脈で最も具体的に書いている部分だ。記事の言い方では、巨大な SBOM だけで悪用可能性の情報がないレガシーアプリはスキャナーを光らせるだけで、ELS は何がパッチ済みで何が悪用可能でないかの署名付き証拠をイメージと一緒に出す。この証拠が実際の監査でどこまで通用するかは監査人と枠組み次第で、記事もそこまでは言っていない。

記事に載っていない条件

料金がない。有料アドオンとだけあって、金額も課金単位も書かれていない。保守される MinIO のバージョンもない。ELS 全般の説明として、指定した系列の最新パッチバージョンで保守する、とあるだけで、MinIO のどの系列が対象かは読み取れない。イメージ名やタグも記事には出てこない。

14 日 の SLA は Critical と High に限られる。Medium 以下の CVE をどう扱うかは記事にない。

もうひとつ、DHI の無料化との関係は Docker のプレスリリースで確かめられる。2025 年 12 月 17 日付のプレスリリースは、1,000 以上の DHI カタログを Apache 2.0 ライセンスで無料公開すると発表し、同時に ELS を DHI Enterprise の有料アドオンと位置づけている。つまり無料の DHI を使うだけでは ELS は付かず、前提になるのは有料の DHI Enterprise だ。その DHI Enterprise の金額は、今回の記事にもプレスリリースにも載っていない。

MinIO を本番で動かしているなら

まず、MinIO がどこで動いているかを棚卸しする。ELS を買うかどうかとは無関係に、上流のパッチが止まっているという前提だけで棚卸しの理由は足りる。アーカイブの事実自体は GitHub のリポジトリで確認できる。

移行先がすでに決まっていて完了が見えているなら、ELS を検討する理由は薄い。記事自身が ELS の役割を、移行がロードマップの日程で進む間、本番にあるイメージへパッチと監査証跡を流し続けることだと説明している。移行が年単位にかかり、その間に監査が入る組織が対象だ。

ELS を検討するなら、Docker に聞くべきことは決まっている。

  • 金額と課金単位
  • 保守対象になる MinIO のバージョンとイメージ名
  • 前提になる DHI Enterprise の契約条件と金額
  • Medium 以下の CVE の扱い

この四つは記事に書かれていない。聞かないと分からない。

一次情報

出典