Docker Hardened Images: container più sicuri partendo dalla base
Quando si parla di sicurezza dei container, il problema spesso nasce prima ancora del Dockerfile: nasce dalla base image. Più pacchetti porti dentro, più ampia diventa la superficie d’attacco.
Le Docker Hardened Images (DHI) nascono proprio per questo: partire da immagini più piccole, più trasparenti e con meno vulnerabilità da gestire.
Cosa vedrai
Cosa sono i Docker Hardened Images
I Docker Hardened Images sono immagini base pensate per essere minimal, trasparenti e più sicure by default.
In pratica, Docker mette a disposizione immagini costruite con un approccio molto più restrittivo rispetto alle classiche official image:
- meno pacchetti installati
- meno tool disponibili nel runtime
- meno CVE da inseguire
- SBOM e provenance più chiari
- catena di build più controllata
Il catalogo dedicato è disponibile su dhi.io e nel catalogo ufficiale Docker. La parte interessante è che puoi cercare per linguaggio o runtime e trovare versioni già pronte all’uso.
Uno dei vantaggi più utili è la trasparenza: sai meglio cosa c’è dentro l’immagine, invece di scoprire tutto solo dopo una scansione.
Come si usano
L’uso quotidiano non cambia molto rispetto alle immagini ufficiali.
Prima di tutto, devi accedere al registry dedicato:
docker login dhi.io
Poi puoi scaricare, ad esempio, la versione Node 22 aggiornata che è stata implementata con focus sulla sicurezza e le performance:
docker pull dhi.io/node:22
La differenza vera arriva quando sostituisci la base image nel Dockerfile. Se la tua app deve installare dipendenze, per alcuni runtime conviene usare una build multi-stage.
Un esempio pratico:
# Build stage
FROM node:22 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install --production
COPY . .
# Production stage
FROM dhi.io/node:22
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package*.json ./
COPY --from=builder /app/server.js ./
EXPOSE 3000
ENV PORT=3000
ENV NODE_ENV=production
CMD ["node", "server.js"]
In questo caso, la build multi-stage ti permette di installare tutte le dipendenze necessarie in un ambiente completo (il builder), e poi copiare solo ciò che serve nel runtime Hardened. In questo modo, il container finale contiene solo i file essenziali per l’esecuzione dell’applicazione.
La ragione della build multi-stage è semplice: nel runtime Hardened non trovi tutto quello che c’è in una classica immagine Node, e questo è intenzionale. Meno strumenti nel container significa meno superficie d’attacco.
Perché conviene
Il punto non è solo “avere meno vulnerabilità” in senso assoluto. Il punto è ridurre il rumore e partire già da una base migliore.
Con le DHI ottieni:
- meno componenti da aggiornare
- meno dipendenze inutili nel runtime
- maggiore chiarezza su ciò che stai distribuendo
- un workflow quasi identico a quello che già usi oggi
In più, se fai un confronto con Docker Scout, vedi subito quanto cambia il profilo di rischio tra una base image tradizionale e una Hardened. Non è magia: è semplicemente una scelta migliore a monte.
docker scout quickview my-image
Ed è qui che si vede il valore reale: non stai solo scansionando dopo, stai prevenendo prima.
Conclusioni
Le Docker Hardened Images sono una scelta molto concreta per chi vuole container più sicuri senza cambiare radicalmente il proprio flusso di lavoro.
Se il tuo obiettivo è ridurre la superficie d’attacco, limitare i pacchetti inutili e avere più trasparenza su quello che distribuisci, DHI è un ottimo punto di partenza.
Risorse utili
🔗 Leggi anche:
Articoli Correlati
