FROM node:22 ——この一行が、あなたのコンテナにOS とシステムライブラリを丸ごと持ち込んでいます。アプリの npm 依存をどれだけ綺麗に更新しても、土台のベースイメージが古ければ、コンテナの CVE は減りません。ベースイメージは、実は最大の依存なのです。
Dependabot の docker エコシステムは、このベースイメージを自動で追従してくれます。この記事はDependabot 本番運用ガイドの各論として、Docker ベースイメージ更新を、再現性とセキュリティの観点から実装レベルで解説します。
この記事のルール：エコシステム名・挙動は GitHub 公式ドキュメントと Dependabot の公開情報（2026年6月時点） に基づきます。Docker Compose の version updates は2025年2月にGAしました。本番前に必ず公式の対応エコシステムで最新を確認してください。
0. ベースイメージが「最大の依存」である理由
あなたのコンテナ = アプリコード
+ アプリ依存（npm/pip/gem …）← 多くの人がここだけ更新する
+ ベースイメージ（OS + システムライブラリ）← 実はここが最大
openssl、glibc、zlib——重大な CVE はしばしばシステムライブラリ側に出ます。これらはベースイメージに含まれるため、ベースイメージを更新しない限り直りません。アプリ依存だけ更新して安心するのは、半分だけの対策です。
1. docker エコシステムの基本
dependabot.yml に docker（および必要なら docker-compose）を追加します。
version: 2
updates:
- package-ecosystem: "docker"
directory: "/" # Dockerfile のある場所
schedule:
interval: "weekly"
commit-message:
prefix: "chore(docker)"
# docker-compose.yml のイメージも更新（2025年2月にGA）
- package-ecosystem: "docker-compose"
directory: "/"
schedule:
interval: "weekly"
Dependabot は Dockerfile の FROM 行や Compose の image: を解析し、新しいタグが出るとPRを開きます。同じ仕組みは Kubernetes マニフェストや Helm チャートの YAML 内イメージにも応用が効きます。
2. タグ更新 vs digest ピン留め
ベースイメージの参照には再現性の段階があります。
| 参照 | 例 | 再現性 | 備考 |
|---|---|---|---|
| 可変タグ | node:22 | 低 | 同じタグでも中身が変わりうる（後述） |
| 版指定タグ | node:22.11.0-bookworm-slim | 中 | より具体的だがタグは可変 |
| digest ピン | node:22-slim@sha256:abc... | 高 | 不変。監査した正確なイメージに固定 |
digest ピン留めの形は次のとおりです。
# タグ＋digest（再現性が高い）
FROM node:22-slim@sha256:1a2b3c4d...
# Dependabot は digest があれば、タグと digest を同時に更新する
@sha256:... が付いていれば、Dependabot はタグと digest をまとめて新しい値へ更新します（GitHub Actions の SHA ピン留めとまったく同じ思想です）。再現性（同じビルドが同じ結果）と更新の自動化を両立できます。
3. silent rebuild：digest ピンが効く理由
「node:22 を指定しているから、いつも同じはず」——これは誤りです。silent rebuild（同じタグのまま、上流メンテナがイメージの中身を差し替えること）が日常的に起きます。セキュリティパッチ適用のための再ビルドは良いことですが、タグだけ見ていると、いつ中身が変わったか分かりません。
ここで digest ピンが効きます。
- digest をピン留めしておくと、上流が同じタグで中身を差し替えても、あなたのビルドは固定したイメージを使い続けます（再現性）。
- 日次で Dependabot を回すと、上流が新しい digest を出したときdigest 更新のPRが来ます。つまり「いつ・何が変わったか」がPRとして可視化され、レビューを経て取り込めます。
- 結果、イメージの CVE rot（放置による脆弱性の蓄積）を構造的に減らせます。
- package-ecosystem: "docker"
directory: "/"
schedule:
interval: "daily" # digest 追従は日次が効く
commit-message:
prefix: "chore(docker)"
「再現性のための固定」と「鮮度のための更新」は矛盾しません。固定（digest ピン）して、PRで更新（Dependabot）する——この組み合わせが、再現性とセキュリティを同時に満たす定石です。
4. マルチステージと最小イメージ
実戦的な Dockerfile はマルチステージです。Dependabot は各ステージの FROM を更新対象にします。
# ---- build stage ----
FROM node:22-slim@sha256:aaa... AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
# ---- runtime stage（最小・非root） ----
FROM gcr.io/distroless/nodejs22-debian12@sha256:bbb... AS runner
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
USER nonroot
CMD ["dist/server.js"]
設計のポイント（コスト効率とセキュリティ）：
- distroless /
-slim/ alpine など最小イメージを選ぶと、攻撃面も CVE 数もイメージサイズ（＝レジストリ・転送コスト）も小さくなります。 - 両ステージとも digest ピンして、Dependabot に追従させます。
- 非root 実行（
USER nonroot）で実行時権限を最小化。
5. プライベートレジストリのベースイメージ
社内 ECR / Artifact Registry / Artifactory のベースイメージも更新できます。docker-registry の認証を registries で定義します。
version: 2
registries:
ecr:
type: docker-registry
url: 111122223333.dkr.ecr.ap-northeast-1.amazonaws.com
username: ${{secrets.DEPENDABOT_AWS_ACCESS_KEY_ID}}
password: ${{secrets.DEPENDABOT_AWS_SECRET_ACCESS_KEY}}
updates:
- package-ecosystem: "docker"
directory: "/"
schedule:
interval: "weekly"
registries: ["ecr"]
ECR は静的AWS認証、Artifact Registry / Artifactory は OIDC も使えます。認証の type 別詳細・self-hosted ランナーはプライベートレジストリ認証ガイドへ。
6. auto-merge は“慎重に”
ベースイメージの更新は、OS とシステムライブラリの変更です。アプリ依存の patch より影響が読みにくいので、auto-merge は一段慎重にします。
- patch / 同一メジャー内の更新（例：
22.11.0→22.11.1、digest 追従）は、ビルド＋スモークテストが通れば自動マージ候補。 - メジャー更新（例：
debian 12 → 13、node 22 → 24）は、glibc やシステムライブラリの非互換が起こりうるため人間レビュー必須。 - イメージスキャンと併用：Dependabot は GitHub Advisory ベースの依存更新が主眼です。コンテナ内パッケージの脆弱性を直接見たいなら、CI に Trivy / Grype 等のイメージスキャンを足し、digest 更新PRでスキャン結果が悪化していないかを確認します（SCA ツールの選び方）。
- name: Auto-merge docker patch / digest bumps
if: |
steps.meta.outputs.package-ecosystem == 'docker' &&
steps.meta.outputs.update-type == 'version-update:semver-patch'
run: gh pr merge --auto --squash "$PR_URL"
env:
PR_URL: ${{ github.event.pull_request.html_url }}
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
auto-merge の token モデルと安全弁（必須チェック）はauto-merge ガイドを参照してください。
7. チェックリスト
-
package-ecosystem: docker（必要ならdocker-compose）を追加 - ベースイメージを
tag@sha256:...で digest ピン留め（再現性） - silent rebuild 対策に 日次スケジュールで digest を追従
- マルチステージで distroless / slim / 非root の最小ランタイム
- プライベートイメージは
docker-registry認証（ECR=静的AWS / Artifact Registry=OIDC） - auto-merge は patch / digest 追従に限定、メジャーは人間レビュー
- CI に Trivy / Grype のイメージスキャンを足し、依存更新と脆弱性検知を両輪に
8. FAQ
Q. FROM node:22 のままでも Dependabot は更新しますか？
A. タグの更新は追えますが、再現性が低く silent rebuild に気づけません。tag@sha256:... で digest ピン留めすると、Dependabot がタグと digest を同時更新し、再現性と鮮度を両立できます。
Q. digest ピンすると更新が止まりませんか？ A. 止まりません。Dependabot が新しい digest/タグへ更新するPRを開きます。日次スケジュールにすると silent rebuild にも追従します。
Q. Docker Compose のイメージも更新できますか？
A. できます。docker-compose エコシステムが2025年2月にGAしました。Dockerfile と併用してください。
Q. ベースイメージを auto-merge してよいですか？ A. patch / digest 追従に限定し、OS メジャー更新は人間レビューにしてください。glibc 等の非互換が起こりえます。
Q. Dependabot だけでコンテナのセキュリティは十分ですか？ A. Dependabot は依存（GitHub Advisory）の更新が主眼です。コンテナ内パッケージの網羅的スキャンは Trivy/Grype を併用してください。役割分担はSCAツール比較で解説します。