コンテナで動いている業務システムを複数抱えていると、月次の脆弱性スキャン結果に同じ CVE が並び続ける状態になりがちです。指摘されているのはアプリのコードではなく、土台になっている OS イメージに含まれるライブラリ。アプリ側で書いたコードには一行も関係がないのに、報告書には自社システムの名前で載ります。
そして担当が決まりません。アプリを作った委託先は「土台は指定されたものを使っただけ」と言い、基盤側は「イメージを固めたのはアプリ側」と言う。翌月も同じ CVE が並びます。
この構図は、担当者の姿勢の問題ではありません。Dockerfile という仕組みが、直す場所をアプリごとに分散させる構造になっているためです。
Dockerfileでは、直す場所がアプリの数だけ増える
Dockerfile では、土台の指定は先頭の FROM 行に書かれます。ベースイメージに脆弱性が見つかったとき、直す作業は「FROM の行を新しいタグに書き換えて、ビルドし直す」ことです。
一見すると軽い作業ですが、そこから先が付いてきます。 フルビルドが走り、CI の実行枠を消費し、テストが一式流れ、デプロイの承認が要る。これがサービスの数だけ発生します。 20サービスあれば20回です。
しかも FROM 行はアプリのリポジトリの中にあります。つまり、直す権限と手順を持っているのはアプリ側のチーム（受託していればその委託先）です。基盤を見ている側は、全社で何がいつ直るかを決められません。 「直してください」と依頼して回るしかない。
毎月同じ CVE が残る理由はここにあります。個々のサービスにとっては「アプリの不具合ではないもののために、テストとデプロイを一式回す」作業であり、優先度が上がらないためです。
再ビルドせずに、土台だけ差し替える
Cloud Native Buildpacks は、Dockerfile を書かずにソースコードから OCI イメージを作る仕組みです。Java・Python・Go・Node.js・Ruby といった言語を検出して、必要なランタイムと依存を組み立てます。
構造として押さえておきたいのは、ビルド時の土台と実行時の土台が分けて管理される点です。ビルダーと呼ばれる OCI イメージが、ビルドパック群とライフサイクル、ビルド時のベースイメージを含み、実行時のベースイメージ（run image）への参照をメタデータとして持ちます。
この分離があるため、実行時の土台が更新されたとき、アプリを再ビルドせずにイメージのレイヤを差し替えられます。 rebase と呼ばれる操作で、コマンド1つです。
差が出るのは規模が大きくなったときです。Dockerfile 方式では20サービス分のビルドとテストとデプロイが必要なところ、rebase であれば土台の層だけを入れ替えて済みます。そして、この操作の起点はアプリのリポジトリではなく、土台を管理している側にあります。
これが「制御点が移る」ということの実務的な意味です。重大な脆弱性にどれだけ速く対応するかを、アプリチームごとの優先度ではなく、基盤側の判断で決められるようになります。
卒業が示しているのは、採用可否の材料
2026年8月11日、CNCF が Cloud Native Buildpacks の卒業を発表しました。CNCF のプロジェクトは Sandbox・Incubating・Graduated の3段階で、卒業は本番採用に足る成熟度に達したという位置づけです。
判断材料として挙げられている内容は次のとおりです。
| 観点 | 内容 |
|---|---|
| 開発体制 | 164組織から535人のコントリビューター |
| 採用実績 | DigitalOcean、GitLab、Google、HashiCorp、Spring、VMware by Broadcom など20以上 |
| セキュリティ検証 | Quarkslab と OSTIF による第三者監査、OpenSSF Best Practices バッジ取得 |
社内で採用を提案する立場からすると、「第三者監査を受けているか」「特定ベンダーに依存していないか」は、機能の議論より先に聞かれる項目です。 卒業の実務的な価値はそこにあります。今後のロードマップとしては、OCI Artifacts の対応拡大、SBOM（ソフトウェア部品表）まわりの強化、WebAssembly への対応が挙げられています。
向かない場合と、契約に書いておく線
万能ではありません。導入前に確認しておく点が2つあります。
ビルドの中身が見えにくくなる。 Dockerfile は手続きが全部書いてあるので、読めば何が入るか分かります。ビルドパックは自動検出で組み立てるため、意図しないものが入っていないかの確認には別の手段（生成された SBOM の確認）が要ります。
特殊なネイティブ依存があると詰まる。 独自のシステムライブラリや、コンパイル時に特殊な手順を要するものは、標準のビルドパックでは扱えないことがあります。この場合は無理に寄せず、Dockerfile のままにしておくほうが保守しやすくなります。
方式をどちらにするにせよ、保守契約で決めておく線は共通です。
- ベースイメージの更新は誰が判断し、誰が作業するのか。 「重大な脆弱性が公表されてから何営業日以内」まで書けると、月次の押し付け合いが消えます
- その作業の費用は保守費に含まれるのか、都度見積もりか。 ここが曖昧だと、依頼のたびに交渉が発生します
- 更新後の動作確認は、どこまでを誰が行うのか。 土台を差し替えても、アプリの動作確認が要らなくなるわけではありません
AI が脆弱性を検出して修正まで出す仕組みが増えたことで、保守契約に何を書くかという論点は脆弱性をAIが直す時代に発注側が決めることでも扱いました。届いた脆弱性報告そのものを検証する話は実在しないCVEが報告される問題にまとめています。
次にやること
コンテナで動いているシステムを持っているなら、直近の脆弱性スキャン結果を開き、指摘のうち何件がベースイメージ由来かを数えてください。 割合が高い場合、アプリ側の改修より土台の更新経路を整えるほうが効きます。
そのうえで、保守契約の文面に「ベースイメージ更新の担当と期限」が書かれているかを確認してください。 書かれていないことのほうが多く、書き足すのは次回更新時で構いません。ただし、書かれていないと分かった時点で、当面は誰かが持つ必要があります。
コンテナ基盤の構成見直し、脆弱性対応フローの整備、既存システムの保守体制の設計については、グリームハブの開発・AI・自動化のご相談で承っています。システムの規模と現在の構成によって進め方が変わるため、個別にお見積りします。お問い合わせからご相談ください。
Sources
- CNCF Announces Graduation of Cloud Native Buildpacks, Advancing the Standard for Container Builds — CNCF
- Buildpacks Move the Container Hardening Control Point Away From the Dockerfile — InfoQ
- コードからDockerfile不要でOCIコンテナをビルド。「Cloud Native Buildpacks」がCNCFの卒業プロジェクトに — Publickey
- Getting Started — Cloud Native Buildpacks
- Cloud Native Buildpacks Achieves Full CNCF Graduation Status — Open Source For You
