GH Copilot says these are the DHIs we could consider using:
Searched for files matching **/Dockerfile*, 5 matches
Searched for regex ^FROM (**/Dockerfile*), 8 results
Fetched https://www.docker.com/products/hardened-images/
Fetched https://hub.docker.com/hardened-images/catalog
Yes — four of the six distinct base images have direct DHI equivalents. Here's the rundown:
| Dockerfile |
Current image |
DHI equivalent |
Notes |
| Dockerfile (builder) |
mcr.microsoft.com/dotnet/sdk:8.0.416-jammy |
dhi/dotnet |
Alpine/Debian, CIS/FIPS/STIG |
| Dockerfile (runtime) |
mcr.microsoft.com/dotnet/aspnet:8.0.22-jammy |
dhi/aspnetcore |
Alpine/Debian, CIS/FIPS/STIG |
| Dockerfile (frontend builder) |
node:22.21.1-bookworm-slim |
dhi/node |
Alpine/Debian, CIS/FIPS/STIG, Extended Lifecycle Support |
| Dockerfile (nginx runtime) |
nginx:1.29.4 |
dhi/nginx |
Alpine/Debian, CIS/FIPS/STIG, Extended Lifecycle Support |
| Dockerfile / Dockerfile |
python:3.12.12-slim-bookworm |
dhi/python |
Alpine/Debian, CIS/FIPS/STIG, Extended Lifecycle Support |
| Dockerfile |
mongo:7.0.30-jammy |
dhi/mongodb |
linux/amd64 only (no arm64) — check your deployment arch |
| Dockerfile |
public.ecr.aws/thecombine/aws-kubectl:0.4.2 |
❌ No DHI equivalent |
Custom project image; not replaceable |
A few notes on adopting DHI:
- Drop-in replacement: DHI advertises these as drop-in swaps — change the
FROM line and update the digest. However, the tag scheme differs (DHI uses its own versioning), so you'd need to verify the exact tag and re-pin the digest.
- MongoDB architecture caveat: The DHI MongoDB image only supports
linux/amd64, so if your deployment includes arm64 nodes, you'd need to stick with the upstream image.
- Microsoft images:
mcr.microsoft.com/dotnet/* are already maintained by Microsoft with security patching. Switching to DHI equivalents adds near-zero-CVE SBOMs and SLSA Build L3 provenance, but isn't strictly necessary if you trust Microsoft's cadence.
- Builder-only stages: The
node and python (in Dockerfile) and dotnet/sdk images are only used in multi-stage build stages — they never ship to production — so the security benefit of hardening them is lower than for the runtime stages (nginx, aspnetcore).
GH Copilot says these are the DHIs we could consider using:
Searched for files matching
**/Dockerfile*, 5 matchesSearched for regex
^FROM(**/Dockerfile*), 8 resultsFetched https://www.docker.com/products/hardened-images/
Fetched https://hub.docker.com/hardened-images/catalog
Yes — four of the six distinct base images have direct DHI equivalents. Here's the rundown:
mcr.microsoft.com/dotnet/sdk:8.0.416-jammydhi/dotnetmcr.microsoft.com/dotnet/aspnet:8.0.22-jammydhi/aspnetcorenode:22.21.1-bookworm-slimdhi/nodenginx:1.29.4dhi/nginxpython:3.12.12-slim-bookwormdhi/pythonmongo:7.0.30-jammydhi/mongodbpublic.ecr.aws/thecombine/aws-kubectl:0.4.2A few notes on adopting DHI:
FROMline and update the digest. However, the tag scheme differs (DHI uses its own versioning), so you'd need to verify the exact tag and re-pin the digest.linux/amd64, so if your deployment includesarm64nodes, you'd need to stick with the upstream image.mcr.microsoft.com/dotnet/*are already maintained by Microsoft with security patching. Switching to DHI equivalents adds near-zero-CVE SBOMs and SLSA Build L3 provenance, but isn't strictly necessary if you trust Microsoft's cadence.nodeandpython(in Dockerfile) anddotnet/sdkimages are only used in multi-stage build stages — they never ship to production — so the security benefit of hardening them is lower than for the runtime stages (nginx,aspnetcore).