# Dependabot で Docker ベースイメージを安全に更新する：タグ追従・digest ピン留め・silent rebuild 対策 > Dockerfile / Docker Compose のベースイメージを Dependabot で安全に更新し続ける実装ガイド。公式ドキュメント（2026年6月時点）に忠実に、docker / docker-compose エコシステムの設定、タグ更新と digest ピン留め（image:tag@sha256:...）の違い、silent rebuild で増える CVE への対策、マルチステージ・プライベートレジストリ（ECR/Artifact Registry）連携、auto-merge を慎重にする理由までを、コピペできる実コードで解説します。 - 公開日: 2026-06-28 - 著者: 友田 陽大 - タグ: Dependabot, Docker, サプライチェーンセキュリティ, DevSecOps, 依存関係管理, セキュリティ - URL: https://tomodahinata.com/blog/dependabot-docker-base-image-digest-pinning-updates-guide - カテゴリ: Dependabot・依存関係の自動更新 - 総合ガイド: https://tomodahinata.com/blog/dependabot-production-guide ## 要点 - ベースイメージは『最大の依存』。OSとシステムライブラリが丸ごと入るため、放置するとアプリ依存を更新しても土台に CVE が積もり続ける。Dependabot の docker エコシステムで自動追従する - FROM node:22 のようなタグ参照は可変。image:tag@sha256:... と digest をピン留めすれば再現性が上がり、digest がある場合 Dependabot はタグと digest を同時に更新する - silent rebuild（同じタグでも上流が中身を差し替える）対策として、digest ピン留め＋日次 Dependabot で digest を追従させると、イメージの CVE rot を構造的に減らせる - Docker Compose のバージョン更新は2025年2月にGA。Dockerfile と Compose 両方を対象にでき、Kubernetes/Helm の YAML 内イメージにも応用が効く - ベースイメージの auto-merge は慎重に。OS のメジャー更新（例 debian 12→13）は挙動が変わりうるため patch/同一メジャー内に限定し、メジャーは人間レビュー＋イメージスキャン（Trivy 等）と併用する --- `FROM node:22` ——この一行が、あなたのコンテナに**OS とシステムライブラリを丸ごと**持ち込んでいます。アプリの npm 依存をどれだけ綺麗に更新しても、**土台のベースイメージが古ければ、コンテナの CVE は減りません**。ベースイメージは、実は**最大の依存**なのです。 Dependabot の `docker` エコシステムは、このベースイメージを自動で追従してくれます。この記事は[Dependabot 本番運用ガイド](/blog/dependabot-production-guide)の各論として、**Docker ベースイメージ更新**を、再現性とセキュリティの観点から実装レベルで解説します。 > **この記事のルール**：エコシステム名・挙動は **GitHub 公式ドキュメントと Dependabot の公開情報（2026年6月時点）** に基づきます。Docker Compose の version updates は2025年2月にGAしました。本番前に必ず[公式の対応エコシステム](https://docs.github.com/en/code-security/reference/supply-chain-security/supported-ecosystems-and-repositories)で最新を確認してください。 --- ## 0. ベースイメージが「最大の依存」である理由 ```text あなたのコンテナ = アプリコード + アプリ依存（npm/pip/gem …）← 多くの人がここだけ更新する + ベースイメージ（OS + システムライブラリ）← 実はここが最大 ``` `openssl`、`glibc`、`zlib`——重大な CVE はしばしば**システムライブラリ**側に出ます。これらはベースイメージに含まれるため、**ベースイメージを更新しない限り直りません**。アプリ依存だけ更新して安心するのは、半分だけの対策です。 --- ## 1. docker エコシステムの基本 `dependabot.yml` に `docker`（および必要なら `docker-compose`）を追加します。 ```yaml 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 ピン留めの形は次のとおりです。 ```dockerfile # タグ＋digest（再現性が高い） FROM node:22-slim@sha256:1a2b3c4d... # Dependabot は digest があれば、タグと digest を同時に更新する ``` **`@sha256:...` が付いていれば、Dependabot はタグと digest をまとめて新しい値へ更新**します（[GitHub Actions の SHA ピン留め](/blog/dependabot-github-actions-sha-pinning-supply-chain-security-guide)とまったく同じ思想です）。再現性（同じビルドが同じ結果）と更新の自動化を両立できます。 --- ## 3. silent rebuild：digest ピンが効く理由 「`node:22` を指定しているから、いつも同じはず」——これは**誤り**です。**silent rebuild**（同じタグのまま、上流メンテナがイメージの中身を差し替えること）が日常的に起きます。セキュリティパッチ適用のための再ビルドは良いことですが、**タグだけ見ていると、いつ中身が変わったか分かりません**。 ここで digest ピンが効きます。 - **digest をピン留め**しておくと、上流が同じタグで中身を差し替えても、あなたのビルドは**固定したイメージ**を使い続けます（再現性）。 - **日次で Dependabot を回す**と、上流が新しい digest を出したとき**digest 更新のPR**が来ます。つまり「**いつ・何が変わったか**」がPRとして可視化され、レビューを経て取り込めます。 - 結果、**イメージの CVE rot（放置による脆弱性の蓄積）を構造的に減らせます**。 ```yaml - package-ecosystem: "docker" directory: "/" schedule: interval: "daily" # digest 追従は日次が効く commit-message: prefix: "chore(docker)" ``` > 「再現性のための固定」と「鮮度のための更新」は矛盾しません。**固定（digest ピン）して、PRで更新（Dependabot）する**——この組み合わせが、再現性とセキュリティを同時に満たす定石です。 --- ## 4. マルチステージと最小イメージ 実戦的な Dockerfile はマルチステージです。Dependabot は**各ステージの `FROM`** を更新対象にします。 ```dockerfile # ---- 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` で定義します。 ```yaml 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 ランナーは[プライベートレジストリ認証ガイド](/blog/dependabot-private-registries-authentication-self-hosted-runners-guide)へ。 --- ## 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 ツールの選び方](/blog/dependabot-vs-snyk-trivy-npm-audit-sca-tools-comparison-guide)）。 ```yaml - 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 ガイド](/blog/dependabot-auto-merge-github-actions-automation-guide)を参照してください。 --- ## 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ツール比較](/blog/dependabot-vs-snyk-trivy-npm-audit-sca-tools-comparison-guide)で解説します。