Immagini Docker Sicure con Trivy e Docker Scout — Hardening che Riduce le Vulnerabilità Reali

Se buildi immagini Docker e non le scannerizzi, stai pubblicando vulnerabilità in produzione. Lo vediamo quotidianamente nei progetti che ci arrivano: immagini piene di librerie obsolete, layer che pesano centinaia di megabyte, backdoor DICOM dimenticate. Un cliente e-commerce aveva un'immagine Node con 47 vulnerabilità critiche — nessuno le aveva mai controllate. Noi, di Meteora Web, veniamo dalla gestione di server reali (Linux, sicurezza, CI/CD) e sappiamo che la sicurezza delle immagini non è un optional: è il punto in cui la tua infrastruttura diventa fragile o solida.

Questa guida è per chi ha già dimestichezza con Docker e vuole un metodo pratico per ridurre i rischi. Parliamo di due strumenti chiave — Trivy e Docker Scout — e delle tecniche di hardening che hanno senso nel mondo reale. Niente teoria fine a sé stessa: comandi che esegui oggi, Dockerfile che riscrivi subito, pipeline che modifichi domani.

Perché le immagini Docker sono il punto debole della tua sicurezza?

Un'immagine Docker è un sistema operativo minimale con sopra la tua applicazione. Se parti da ubuntu:latest senza pulire i pacchetti non necessari, porti in produzione centinaia di CVE potenziali. Il problema non è solo la base image: ogni RUN apt-get install o npm install aggiunge layer con vulnerabilità. E se non scansionate, rimangono lì finché qualcuno non le sfrutta.

L'errore più comune? Usare immagini tagliate :latest o :alpine senza verificarne il contenuto. Un'immagine Alpine è più piccola, ma ha il suo carico di CVE (e la musl libc non sempre compatibile).

Cosa fare subito

• Non usare :latest nei Dockerfile di produzione — usa tag fissi come :20.04 o hash specifici.
• Esegui una scansione iniziale con Trivy sulla tua immagine attuale: trivy image nome-immagine.
• Se trovi vulnerabilità critiche, non ignorarle: pianifica la correzione entro 72 ore.

Come funziona Trivy per la scansione delle vulnerabilità?

Trivy (dalla parola giapponese 'trivy' che significa 'vulnerabilità') è un tool open-source leggero, veloce e integrato con database CVE multipli (NVD, Red Hat, Debian, Alpine, GitHub Advisory). Scansiona immagini Docker, filesystem, repository Git e manifest IaC. Noi lo usiamo in ogni pipeline che gestiamo.

Installazione e primo scan

# Installazione su Linux (Debian/Ubuntu)
sudo apt-get update
sudo apt-get install trivy

# Scansione di un'immagine locale
trivy image --severity CRITICAL,HIGH --ignore-unfixed myapp:latest

L'opzione --ignore-unfixed mostra solo le vulnerabilità per cui esiste una patch già disponibile. Questo ti evita di inseguire CVE non risolvibili. Attenzione: non vuol dire che puoi ignorarle, ma ti aiuta a prioritizzare.

Integrazione in CI/CD (GitHub Actions esempio)

- name: Scan image with Trivy
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'myapp:${{ github.sha }}'
    format: 'sarif'
    output: 'trivy-results.sarif'
    severity: 'CRITICAL,HIGH'
    ignore-unfixed: true

Il formato SARIF permette di visualizzare i risultati direttamente in GitHub Security. Se preferisci bloccare la pipeline con vulnerabilità critiche, puoi aggiungere exit-code: 1.

Trivy oltre le immagini

Trivy scansiona anche file system (per progetti non containerizzati), repository Git (per codice open-source) e manifest IaC (Terraform, CloudFormation). Lo usiamo per verificare le dipendenze di un cliente che aveva un monolite PHP: trivy filesystem --scanners vuln,secret /var/www. Ha trovato chiavi API hardcoded e librerie obsolete.

Consiglio pratico: esegui Trivy anche sui tuoi Dockerfile prima del build con trivy config --severity HIGH Dockerfile per trovare problemi di configurazione (es. USER root, porte esposte inutili).

Docker Scout: l'integrazione nativa che non ti aspetti

Docker Scout è il servizio di sicurezza integrato in Docker Desktop e Docker Hub. Rispetto a Trivy, offre analisi continua e raccomandazioni contestuali. Se Trivy è il termometro, Scout è il medico che ti dice quali medicine prendere.

Attivare Docker Scout

# Abilitare Scout sul tuo account Docker (gratuito per singoli sviluppatori)
docker scout quickview myapp:latest

Scout confronta la tua immagine con il database di vulnerabilità e propone aggiornamenti delle dipendenze. Ma la vera forza è Docker Scout Dashboard, che mostra le vulnerabilità di tutte le immagini nel tuo registry in un'unica vista.

Policy basate su severità

Puoi definire delle policy: per esempio, bloccare il deploy se una vulnerabilità critica non è risolta da più di 30 giorni. Questo evita che le vulnerabilità si accumulino senza controllo.

# Analisi di un'immagine remota
docker scout compare myapp:latest --to myapp:production

Il comando compare mostra la differenza di vulnerabilità tra due versioni. Lo usiamo per verificare che un aggiornamento non introduca nuove CVE.

Trivy + Docker Scout: meglio insieme

Non è un aut-aut. Noi consigliamo di usarli entrambi: Trivy per scansioni veloci in CI (gratuito, open-source, veloce), Docker Scout per monitoraggio continuo e raccomandazioni. La combinazione copre lo sviluppo e la produzione.

Quali sono le tecniche di hardening immagine più efficaci?

La scansione è inutile se non risolvi le vulnerabilità. Ecco le tecniche che applichiamo ogni giorno.

1. Usa immagini base minimali e distroless

Invece di ubuntu:22.04 (che include più di 100 pacchetti), usa immagini distroless (mantenute da Google) o basate su scratch. Distroless contiene solo la runtime e le dipendenze strettamente necessarie. Riduci la superficie d'attacco del 90%.

# Dockerfile con distroless per Node
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production && npm cache clean --force

FROM gcr.io/distroless/nodejs20-debian12
COPY --from=build /app /app
USER 1000
CMD ["/app/node_modules/.bin/node", "/app/server.js"]

Attenzione: le immagini distroless non hanno shell, quindi non puoi eseguire exec interattivo in produzione. È una scelta di sicurezza voluta.

2. Multi-stage build per ridurre i layer

Separa l'ambiente di build (con tool come git, gcc, npm) dall'immagine finale. I tool di build non arrivano in produzione.

# Primo stage: build
FROM golang:1.22-alpine AS builder
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /app/myapp

# Secondo stage: deployment
FROM gcr.io/distroless/static-debian12
COPY --from=builder /app/myapp /myapp
EXPOSE 8080
USER 1000
CMD ["/myapp"]

3. Non eseguire come root

L'utente di default nei container è root. Cambia utente con USER e assicurati che l'utente esista (o usa --user nel comando di esecuzione).

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

4. Pulisci pacchetti, cache e permessi

Dopo un apt-get install, pulisci la cache: rm -rf /var/lib/apt/lists/*. Imposta file read-only dove possibile.

RUN apt-get update && apt-get install -y --no-install-recommends \
    ca-certificates \
    && rm -rf /var/lib/apt/lists/*

5. Usa --squash solo in fase di build (sperimentale)

Il flag --squash durante il docker build appiattisce i layer, riducendo la superficie e il numero di CVE nei layer intermedi. Non è standard ma in contesti controllati funziona.

Come combinare Trivy e Docker Scout in una pipeline CI/CD?

Ecco uno schema che seguiamo per i nostri clienti:

1. Build multi-stage → riduci al minimo l'immagine.
2. Trivy scan su ogni push → blocco se critiche non-ignorate.
3. Docker Scout quickview in post-build → report su dashboard.
4. Pubblica immagine su Docker Hub o registry privato con Scout attivato → monitoraggio continuo.
5. Policy Scout → blocca il deploy di immagini con vulnerabilità aperte da più di 30 giorni.

In pratica, un workflow GitHub Actions potrebbe assomigliare a questo:

name: Build, Scan, Push
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
      - name: Scan with Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:${{ github.sha }}
          severity: CRITICAL,HIGH
          exit-code: 1
      - name: Docker Scout scan
        run: |
          docker scout quickview myapp:${{ github.sha }}
      - name: Push
        run: |
          docker tag myapp:${{ github.sha }} myrepo/myapp:latest
          docker push myrepo/myapp:latest

Nota: se usi Docker Scout, assicurati di aver effettuato il login con docker scout auth.

Cosa fare adesso

Non aspettare che una vulnerabilità critica venga sfruttata. Ecco tre azioni immediate:

1. Scansiona le tue immagini attuali con trivy image nome-immagine e prioritizza le critiche e alte.
2. Riscrivi il Dockerfile usando multi-stage e immagini distroless o alpine minimizzate. Rimuovi pacchetti non necessari e cambia utente.
3. Integra Trivy nella tua CI (GitHub Actions, GitLab CI, Jenkins). Se usi Docker Scout, attiva la dashboard e imposta policy di blocco.

Noi, di Meteora Web, abbiamo visto immagini con 50+ vulnerabilità che nessuno aveva mai controllato. Correre ai ripari dopo un incidente è cento volte più costoso. La sicurezza delle immagini è un processo, non un evento. Inizia oggi.

Per approfondire l'intero ecosistema della sicurezza cloud, leggi la nostra guida pillar su Cloud Security e DevSecOps.

Riferimenti utili: Trivy su GitHub | Docker Scout Documentation.