Investigate using Docker Hardened Images

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:

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).

Review the five Dockerfile* matches and the eight FROM lines identified in the issue. Compare the relevant DHI tags and digest-pinning requirements, then check runtime versus builder stages and the MongoDB linux/amd64 limitation. Done means documenting a justified image-by-image recommendation, including cases where the current image should remain.