{"id":2804,"date":"2025-10-22T18:32:44","date_gmt":"2025-10-22T17:32:44","guid":{"rendered":"https:\/\/andylockran.dev\/?p=2804"},"modified":"2025-10-22T19:26:16","modified_gmt":"2025-10-22T18:26:16","slug":"how-do-you-keep-your-dockerfile-from-sha-tags-up-to-date","status":"publish","type":"post","link":"https:\/\/andylockran.dev\/index.php\/2025\/10\/22\/how-do-you-keep-your-dockerfile-from-sha-tags-up-to-date\/","title":{"rendered":"How do you keep your Dockerfile FROM sha tags up to date?"},"content":{"rendered":"\n

For my trusty followers who have been crying out for a technology-based post – TODAY IS THE DAY.<\/p>\n\n\n\n

Due to recent supply chain attacks; more platforms are going down the route of suggesting sha-pinning dependencies<\/p>\n\n\n\n

GitHub has a flag that ensures that all your GitHub Action dependencies are explicitly tied to a sha<\/a>, instead of just a version tag (e.g. @v1)<\/p>\n\n\n\n

This helps to put you in control of version upgrades, as each time the author releases a new version.<\/p>\n\n\n\n

In the npm world, your package.json file defines the ‘range’ of dependencies that you ‘directly’ depend on, and the package-lock.json is a reference to all of the reified dependency tree versions that were pulled when you ‘built’ the package. <\/p>\n\n\n\n

This produced repeatable builds (when using `npm ci`), as it only ever downloaded the dependencies ‘pinned’ by the lockfile. As npm follows SemanticVersioning, when new packages are updated, the dependency tree is re-worked out, and dependabot can make suggestions for how to update your package-lock.json file to satisfy both generic updates, and security patches.<\/p>\n\n\n\n

It’s great for npm (SemVer), it’s great for GHA (SemVer), but it’s also capable of supporting Dockerfiles.<\/p>\n\n\n\n

FROM node:20-alpine<\/code><\/pre>\n\n\n\n
An innocuous Dockerfile, build using the Official Node image, and follows Docker’s own documentation<\/a> (from 2022).<\/p>\n\n\n\n
Way back in 2020, the first hit (for me) on Google is B\u00e1lint Bir\u00f3<\/a><\/a>‘s helpful blogpost on how to follow this approach for Docker images within the context of tools like docker-compose; and the official Dockerfile doc<\/a> shows how to do this using the FROM argument in a dockerfile:<\/p>\n\n\n\n
FROM node:20-alpine@sha256:3bc9a4c4cc25cfde1e8f946341c85f333c36517aafda829b4bb7e785e9b5995c <\/code><\/pre>\n\n\n\n
Neat.<\/p>\n\n\n\n
However, the management of these images in DockerHub is kinda a different paradigm.  The office ‘node’ image, of which 20-alpine<\/code> is just a label, has quite a load of other labels:<\/p>\n\n\n\n
https:\/\/hub.docker.com\/_\/node<\/a><\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
There are tens of labels, and the label I’ve targeted is mutable. It automatically keeps me up to date whenever the official maintainers release a new version.  However, it’s the same anti-pattern as the one that Github Actions recently fixed with their sha pinning.  <\/p>\n\n\n\n
\n
So, if I want to maintain 20-alpine, and I want to pin to a sha, so that I only get an update if the maintainer posts a new version of the 20-alpine label to docker hub, that’s possible right?<\/p>\n<\/blockquote>\n\n\n\n
Well, I tested it and put a Dockerfile the following:<\/p>\n\n\n\n
FROM node:20-alpine@sha256:3bc9a4c4cc25cfde1e8f946341c85f333c3<\/code>6517aafda829b4bb7e785e9b5995c<\/code><\/pre>\n\n\n\n
and a dependabot.yml like so:<\/p>\n\n\n\n
# To get started with Dependabot version updates, you'll need to specify which\n# package ecosystems to update and where the package manifests are located.\n# Please see the documentation for all configuration options:\n# https:\/\/docs.github.com\/github\/administering-a-repository\/configuration-options-for-dependency-updates\n\nversion: 2\nupdates:\n  - package-ecosystem: \"npm\" # See documentation for possible values\n    directory: \"\/\" # Location of package manifests\n    schedule:\n      interval: \"weekly\"\n  - package-ecosystem: \"github-actions\" # See documentation for possible values\n    directory: \"\/\" # Location of package manifests\n    schedule:\n      interval: \"weekly\"\n  - package-ecosystem: \"docker\"\n    directory: \"\/\" # Location of package manifests\n    schedule:\n      interval: \"daily\"<\/code><\/pre>\n\n\n\n
and to my (un-surprise, as I’d read the docs), it didn’t quite work as anticipated, with the next PR suggesting the following change:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Bump node from 20-alpine to 25-alpine !<\/p>\n\n\n\n
Now, node’s own guidance is as follows:<\/p>\n\n\n\n
\n
Major Node.js versions enter Current<\/em> release status for six months, which gives library authors time to add support for them. After six months, odd-numbered releases (9, 11, etc.) become unsupported, and even-numbered releases (10, 12, etc.) move to Active LTS<\/em> status and are ready for general use. LTS<\/em> release status is “long-term support”, which typically guarantees that critical bugs will be fixed for a total of 30 months. Production applications should only use Active LTS<\/em> or Maintenance LTS<\/em> releases.<\/p>\n<\/blockquote>\n\n\n\n
So this PR is taking me from a current LTS release, in maintenace til April ’26, to a current version that’s never going to enter LTS and not recommended for production use.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
I think that it’s behaving like this because the implementation pattern that the official node maintains have taken to have loads of labels against a single image.  Dependabot for docker isn’t particularly smart, and looks for a temporally later<\/code> tag against the node<\/code> image, rather than using the 20-alpine<\/code> label to contextualise the sha and lock it against the label+sha as defined in my lovely Dockerfile.<\/p>\n\n\n\n
Now, no grief to the maintainers. The pattern that they support is a docker-hub image that uses SemVer in the label to contextualize their dependencies,<\/a> so the nodeJS pattern is just one of many others that fall outside that paradigm. <\/p>\n\n\n\n
A little bit more research…<\/h2>\n\n\n\n
After a quick Google, I went and found a few threads where people were cheering an alternative to dependabot for docker stuff, Renovate, by Mend.<\/p>\n\n\n\n
I’d come across this before, but being a Github native I’d always just deferred to dependabot.<\/p>\n\n\n\n
I had to install the app into my org, trust it with my test repo – but once it had been plumbed in and read my code.. It raised the PR that I wanted – a direct update of the sha for the node:20-alpine tag:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
I can see why Dependabot is struggling; but if renovate is ahead of the game here then I may be rethinking what else it’s picking up on that Dependabot is missing…<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\n
What do you use to manage your dependencies? Is there another dependency bot that’s even better?<\/p>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"
For my trusty followers who have been crying out for a technology-based post – TODAY IS THE DAY. Due to recent supply chain attacks; more platforms are going down the route of suggesting sha-pinning dependencies GitHub has a flag that ensures that all your GitHub Action dependencies are explicitly tied to a sha, instead of […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[1],"tags":[],"class_list":["post-2804","post","type-post","status-publish","format-standard","hentry","category-uncategorised"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack-related-posts":[],"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/andylockran.dev\/index.php\/wp-json\/wp\/v2\/posts\/2804","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/andylockran.dev\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/andylockran.dev\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/andylockran.dev\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/andylockran.dev\/index.php\/wp-json\/wp\/v2\/comments?post=2804"}],"version-history":[{"count":3,"href":"https:\/\/andylockran.dev\/index.php\/wp-json\/wp\/v2\/posts\/2804\/revisions"}],"predecessor-version":[{"id":2813,"href":"https:\/\/andylockran.dev\/index.php\/wp-json\/wp\/v2\/posts\/2804\/revisions\/2813"}],"wp:attachment":[{"href":"https:\/\/andylockran.dev\/index.php\/wp-json\/wp\/v2\/media?parent=2804"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/andylockran.dev\/index.php\/wp-json\/wp\/v2\/categories?post=2804"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/andylockran.dev\/index.php\/wp-json\/wp\/v2\/tags?post=2804"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}