{"id":636,"date":"2026-03-16T06:27:14","date_gmt":"2026-03-16T05:27:14","guid":{"rendered":"https:\/\/compresserimage.com\/blog\/comment-securiser-sa-images-legeres-sans-se-compliquer-la-vie\/"},"modified":"2026-03-16T06:27:14","modified_gmt":"2026-03-16T05:27:14","slug":"comment-securiser-sa-images-legeres-sans-se-compliquer-la-vie","status":"publish","type":"post","link":"https:\/\/compresserimage.com\/blog\/comment-securiser-sa-images-legeres-sans-se-compliquer-la-vie\/","title":{"rendered":"Comment s\u00e9curiser sa images l\u00e9g\u00e8res sans se compliquer la vie"},"content":{"rendered":"


\n<\/p>\n

\n

<\/p>\n

Introduction<\/h2>\n

<\/p>\n

Les images conteneurs l\u00e9g\u00e8res \u2014 alpine<\/code>, distroless<\/code>, scratch<\/code>, slim<\/code> \u2014 sont devenues le standard de facto pour le d\u00e9ploiement moderne. Elles d\u00e9marrer plus vite, consomment moins de m\u00e9moire, r\u00e9duisent la surface d’attaque. Pourtant, paradoxalement, adopter une image slim<\/em> peut introduire des risques invisibles si l’on ne suit pas quelques principes fondamentaux.<\/p>\n

<\/p>\n

Cet article propose une approche pragmatique : s\u00e9curiser ses images l\u00e9g\u00e8res sans transformer chaque build en un exercice de compliance kafka\u00efen.<\/p>\n

<\/p>\n

\n

<\/p>\n

1. Comprendre pourquoi les images l\u00e9g\u00e8res changent la donne s\u00e9curitaire<\/h2>\n

<\/p>\n

Une surface d’attaque r\u00e9duite n’est pas une surface d’attaque nulle<\/h3>\n

<\/p>\n

Une image bas\u00e9e sur node:20-alpine<\/code> contient typiquement 40 \u00e0 60 paquets<\/strong>. La m\u00eame image bas\u00e9e sur node:20<\/code> (Debian full) en contient 500 \u00e0 800<\/strong>. Chaque paquet absent est un CVE potentiel en moins.<\/p>\n

<\/p>\n

Mais attention : une image distroless<\/code> qui n’a ni shell ni gestionnaire de paquets ne peut pas \u00eatre inspect\u00e9e facilement<\/strong> en production. Cela cr\u00e9e un faux sentiment de s\u00e9curit\u00e9 si le code qu’elle contient n’a jamais \u00e9t\u00e9 analys\u00e9.<\/p>\n

<\/p>\n

La r\u00e8gle : une image l\u00e9g\u00e8re est un avantage s\u00e9curitaire seulement si elle embarque un code sain.<\/strong><\/p>\n

<\/p>\n

\n

<\/p>\n

2. Les cinq principes fondamentaux<\/h2>\n

<\/p>\n

Principe 1 : Scanner t\u00f4t, scanner souvent<\/h3>\n

<\/p>\n

Le scan de vuln\u00e9rabilit\u00e9s doit intervenir pendant le CI, pas apr\u00e8s le d\u00e9ploiement<\/strong>.<\/p>\n

<\/p>\n

# Exemple \u2014 GitHub Actions avec Trivy
\n- name: Scan de vuln\u00e9rabilit\u00e9s
\n  uses: aquasecurity\/trivy-action@master
\n  with:
\n    image: mon-app:latest
\n    severity: 'CRITICAL,HIGH'
\n    exit-code: '1'   # Fait \u00e9chouer le build si vuln\u00e9rabilit\u00e9 critique<\/code><\/pre>\n
<\/p>\n
Pourquoi Trivy et pas un autre ? Gratuit, open-source, rapide, couvre les CVE OS et les d\u00e9pendances applicatives (npm, pip, Go modules). Il n’y a pas d’excuse pour ne pas l’int\u00e9grer.<\/p>\n
<\/p>\n
Astuce temps r\u00e9el :<\/strong> Activez le flag --ignore-unfixed<\/code> pour ne bloquer le build que sur les vuln\u00e9rabilit\u00e9s r\u00e9ellement corrig\u00e9es en amont<\/em>. Sinon, vous serez noy\u00e9 dans des faux positifs que personne ne peut traiter.<\/p>\n
<\/p>\n
\n
<\/p>\n
Principe 2 : Le multi-stage build n’est pas optionnel<\/h3>\n
<\/p>\n
C’est le levier le plus puissant, et le plus sous-utilis\u00e9. Le principe est simple : s\u00e9parer le monde de build du monde de runtime<\/strong>.<\/p>\n
<\/p>\n
# \u00c9tape 1 \u2014 Build : tout est install\u00e9 ici
\nFROM golang:1.22-alpine AS builder
\nWORKDIR \/app
\nCOPY go.mod go.sum .\/
\nRUN go mod download
\nCOPY . .
\nRUN CGO_ENABLED=0 go build -ldflags=\"-s -w\" -o \/app\/server .
# \u00c9tape 2 \u2014 Runtime : image minimale, aucune toolchain
\nFROM gcr.io\/distroless\/static-debian12:nonroot
\nCOPY --from=builder \/app\/server \/server
\nUSER nonroot:nonroot
\nENTRYPOINT [\"\/server\"]<\/code><\/pre>\n
<\/p>\n
Ce pattern \u00e9limine automatiquement<\/strong> le compilateur, le gestionnaire de paquets, les headers de d\u00e9veloppement, et tous les outils qui n’ont rien \u00e0 faire en production. R\u00e9sultat : image de ~15 Mo au lieu de ~800 Mo, et z\u00e9ro CVE de toolchain<\/strong>.<\/p>\n
<\/p>\n
\n
<\/p>\n
Principe 3 : Ne jamais ex\u00e9cuter en root<\/h3>\n
<\/p>\n
C’est la r\u00e8gle la plus simple et la plus viol\u00e9e. Une image qui tourne en root, m\u00eame l\u00e9g\u00e8re, peut compromettre l’h\u00f4te entier si une faille d’\u00e9chappement existe.<\/p>\n
<\/p>\n
# Option A \u2014 Utilisateur d\u00e9di\u00e9 (Alpine)
\nRUN addgroup -S appgroup && adduser -S appuser -G appgroup
\nUSER appuser
# Option B \u2014 Utilisateur int\u00e9gr\u00e9 (Distroless)
\nUSER nonroot:nonroot<\/code><\/pre>\n
<\/p>\n
V\u00e9rification rapide :<\/strong><\/p>\n
<\/p>\n
docker run --rm mon-app:latest id
\n# Doit afficher uid=65534(nonroot) \u2014 pas uid=0(root)<\/code><\/pre>\n
<\/p>\n
Si vous utilisez Kubernetes, ajoutez une securityContext<\/code> pour rendre cela explicite et emp\u00eacher toute r\u00e9gression :<\/p>\n
<\/p>\n
securityContext:
\n  runAsNonRoot: true
\n  runAsUser: 65534
\n  readOnlyRootFilesystem: true
\n  allowPrivilegeEscalation: false<\/code><\/pre>\n
<\/p>\n
\n
<\/p>\n
Principe 4 : Signer ses images (sans douleur)<\/h3>\n
<\/p>\n
La signature d’images garantit l’int\u00e9grit\u00e9<\/strong> et la provenance<\/strong>. Avec cosign<\/code> de Sigstore, c’est devenu triviale :<\/p>\n
<\/p>\n
# G\u00e9n\u00e9rer une paire de cl\u00e9s (une seule fois)
\ncosign generate-key-pair
# Signer l'image au moment du push
\ncosign sign --key cosign.key mon-registry.com\/mon-app:v1.2.3
# V\u00e9rifier avant le d\u00e9ploiement
\ncosign verify --key cosign.pub mon-registry.com\/mon-app:v1.2.3<\/code><\/pre>\n
<\/p>\n
Pour aller plus loin : int\u00e9grez cosign verify<\/code> dans votre admission controller Kubernetes (Kyverno ou Gatekeeper). R\u00e9sultat : aucune image non sign\u00e9e ne peut \u00eatre d\u00e9ploy\u00e9e<\/strong>, point final.<\/p>\n
<\/p>\n
\n
<\/p>\n
Principe 5 : R\u00e9duire les secrets \u00e0 z\u00e9ro dans l’image<\/h3>\n
<\/p>\n
Les secrets dans les images Docker sont le p\u00e9ch\u00e9 originel du container security. Un docker history mon-app<\/code> r\u00e9v\u00e8le chaque couche, y compris les secrets qui y ont \u00e9t\u00e9 copi\u00e9s \u2014 m\u00eame s’ils ont \u00e9t\u00e9 supprim\u00e9s ensuite.<\/p>\n
<\/p>\n
Ce qu’il ne faut JAMAIS faire :<\/strong><\/p>\n
<\/p>\n
# \u274c Catastrophe
\nCOPY .env \/app\/.env
\nENV DATABASE_URL=postgres:\/\/user:p4ss@host\/db<\/code><\/pre>\n
<\/p>\n
Ce qu’il faut faire :<\/strong><\/p>\n
<\/p>\n