Comment analyser les images de conteneurs dans un pipeline CI/CD ?
Réponse courte
Analysez les images pour les CVE connues dans les paquets OS et les bibliothèques applicatives, ainsi que les mauvaises configurations et les secrets intégrés, à la fois au moment du build et en continu dans le registre — car de nouvelles CVE apparaissent après la construction d'une image. Utilisez des images de base minimales ou distroless pour réduire la surface d'attaque, épinglez et référencez les images de base par empreinte, et exécutez le conteneur en non-root. L'analyse est nécessaire mais ne remplace pas la protection à l'exécution.
Une image de conteneur est une pile de couches — un OS de base, des paquets, des bibliothèques et votre application — et n'importe quelle couche peut porter une vulnérabilité. L'analyse d'images est la façon de garder cette pile honnête.
Ce que l'analyse trouve
Un scanner (Trivy, Grype, Clair, ou le scanner intégré d'un registre) inspecte chaque couche et signale :
- Les CVE connues dans les paquets OS (l'image de base) et les dépendances applicatives.
- Les mauvaises configurations — exécution en root, secrets cuits dans une couche, capacités dangereuses, utilisateur manquant.
- Les secrets intégrés copiés accidentellement dans l'image.
Analyser au build et dans le registre
C'est le point que les candidats manquent souvent. L'analyse au moment du build dans la CI donne un retour rapide et peut faire échouer le build. Mais une image propre hier ne l'est pas pour toujours — de nouvelles CVE sont divulguées contre des paquets déjà présents à l'intérieur. Vous analysez donc aussi en continu dans le registre, pour qu'une image désormais connue comme vulnérable soit signalée (et idéalement bloquée au déploiement) même si rien n'a changé en elle.
Réduire la surface d'attaque
Les vulnérabilités les moins chères à corriger sont celles que vous ne livrez jamais. Les images de base minimales ou distroless suppriment les shells, gestionnaires de paquets et bibliothèques inutilisées, donc il y a simplement moins de choses vulnérables et moins de choses utilisables par un attaquant après compromission. Épinglez les images de base par empreinte (pas seulement :latest), reconstruisez régulièrement pour récupérer les correctifs, et exécutez en utilisateur non-root.
L'analyse n'est pas la ligne d'arrivée
L'analyse d'images est statique — elle ne peut pas voir ce qu'un conteneur en cours d'exécution fait réellement. Associez-la à la sécurité à l'exécution (contrôle d'admission, détection de dérive, surveillance comportementale) pour avoir le tableau complet.
Ce que recherchent les recruteurs
Ils veulent que l'analyse au build et dans le registre soit expliquée, l'instinct de l'image de base minimale, et la conscience qu'analyser une image connue comme bonne nécessite quand même d'y revenir à mesure que de nouvelles CVE apparaissent.
Questions de suivi probables
- Pourquoi analyser les images dans le registre si vous les avez déjà analysées au build ?
- Comment les images de base minimales ou distroless réduisent-elles le risque ?
- Que manque l'analyse d'images que la sécurité à l'exécution détecte ?