node:22-bookwormに最新パッチが入ったかはダイジェストで確認する

  • Docker
  • Node.js
  • AWS
  • ECR

この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。

2026年10月21日にNode.jsのセキュリティリリースが出て、22.x系は v22.23.4 が修正版になった。手元のサービスはCodePipelineでECSにデプロイしていて、Dockerfileはこう書いている。

FROM public.ecr.aws/docker/library/node:22-bookworm AS build

パッチバージョンを固定していないので、パイプラインを回し直せば最新パッチが入るはず。ただし、それは「22-bookworm タグがもう 22.23.4 を指している」場合に限る。そこをどう確認するかで少し迷った。

Dockerfileを見ても判断できない

最初に nodejs/docker-node リポジトリの 22/bookworm/Dockerfile を見たら、ENV NODE_VERSION は 22.23.4 になっていた。ただ、これは「次にビルドされるイメージの中身」で、配布されているタグがもう更新済みという意味ではない。

公式イメージがタグに反映されるまでの流れはだいたいこうなっている。

flowchart LR
  A["nodejs/docker-node<br/>DockerfileのNODE_VERSION更新"] --> B["docker-library/official-images<br/>library/nodeのTags更新"]
  B --> C["Docker Hubでビルド・push"]
  C --> D["ECR Publicにミラー"]

public.ecr.aws/docker/library/node はDocker Hub公式イメージのミラーなので、一番右まで進んで初めて自分のビルドに効く。

途中の official-images の library/node ファイルも参考にはなる。Tags: の行に 22.23.4-bookworm が並んでいれば、タグの付け替えが決まった段階まで来ている。ただ、GitHubのページ表示が古いまま返ってくることがあって、自分はこれで「まだ22.23.2のまま」と一度判断を誤った。実際には、Docker Hub側はその時点でもう更新されていた。

結局、確実なのは配布されているタグそのものを見ることだった。

方法1: パッチ固定タグとダイジェストを比べる

22-bookworm も 22.23-bookworm も 22.23.4-bookworm も、指している先が同じなら中身も同じ。なので、パッチ固定タグとダイジェスト（マニフェストリストのハッシュ）を比べればいい。

ECR Publicなら docker buildx imagetools inspect でpullせずに見られる。

ターミナル
docker buildx imagetools inspect public.ecr.aws/docker/library/node:22-bookworm
docker buildx imagetools inspect public.ecr.aws/docker/library/node:22.23.4-bookworm

出力の先頭にある Digest: が両方同じなら、22-bookworm はもう 22.23.4 を指している。

Docker Hub側を見たいときは、Hub APIでもタグごとのダイジェストと更新日時が取れる。

ターミナル
curl -s https://hub.docker.com/v2/repositories/library/node/tags/22-bookworm \
  | jq '{digest, last_updated}'
curl -s https://hub.docker.com/v2/repositories/library/node/tags/22.23.4-bookworm \
  | jq '{digest, last_updated}'

今回は、両方とも sha256:63538dfe…3f3384 で一致していた。22-bookworm の last_updated は 2026-10-22T02:38Z で、リリースの翌日（UTC）には付け替わっていたことになる。22.23-bookworm も同じダイジェストだった。

ただし、Hub APIで見えるのはDocker Hub側の状態だけで、ECR Publicへのミラーが終わっているかまでは分からない。実際にpullする先が public.ecr.aws なら、imagetools inspect のほうで確認しておくほうが安心。

パッチ固定タグがまだ存在しない場合は、22.23.4-bookworm のinspectがエラーになる。それ自体が「まだ来ていない」という答えになる。

方法2: イメージ設定のNODE_VERSIONを見る

比較対象のタグを用意しなくても、イメージの設定（config）にある環境変数を見れば中身のバージョンが分かる。公式のnodeイメージは NODE_VERSION を ENV で持っている。

ターミナル
docker buildx imagetools inspect \
  public.ecr.aws/docker/library/node:22-bookworm \
  --format '{{json .Image}}' \
  | jq -r '."linux/amd64".config.Env[]' | grep NODE_VERSION

マルチプラットフォームのイメージだと、.Image はプラットフォームをキーにしたマップで返ってくるので、linux/amd64 などを指定して取り出す。ARMのFargateで動かしているなら linux/arm64 を見る。

これもpull不要。

方法3: 実際に動かして node -v

一番分かりやすいのは、やっぱりコンテナを起動してみること。

ターミナル
docker run --rm public.ecr.aws/docker/library/node:22-bookworm node -v

bookwormのフルイメージは400MB前後あるので、確認のためだけにpullするのは少し重い。ただ、CI上ならついでにできる。

CIで回すときの注意

タグが更新されていても、ビルド環境に古いベースイメージが残っていると、そっちが使われることがある。

  • CodeBuildでローカルキャッシュ（Docker layer cache）を有効にしている、または --cache-from を使っている場合は、docker build --pull を付けておく。--pull を付けると、ベースイメージのタグを毎回レジストリに問い合わせるようになる。
  • マルチステージビルドなら、ビルドステージだけでなく最終ステージの FROM も同じように確認する。
  • ビルドログに node -v を出しておくと、デプロイ後に「本当に上がったか」を後から追える。たとえば RUN node -v をDockerfileに1行入れておくか、ビルドしたイメージで docker run --rm <image> node -v を実行する。

確実に特定のパッチを当てたいなら、一時的に node:22.23.4-bookworm に固定するのもあり。タグがまだなければビルドがpullで失敗するので、反映前に回してしまう事故も防げる。固定しっぱなしだと次のパッチを自分で追う必要が出るので、落ち着いたらパッチ未指定のタグに戻すかどうかは運用次第。

結局どれを使うか

  • 反映済みかだけ知りたい：imagetools inspect でパッチ固定タグとダイジェストを比較する
  • 比較対象のタグが分からない、中身のバージョンを直接見たい：NODE_VERSION を見る
  • ビルド結果として保証したい：CIで --pull を付けてビルドし、ログに node -v を出す

GitHubのDockerfileや official-images のファイルは「これから反映される」目安としては使えるけど、判断材料にはしないほうがいい。