Le distroless aveugle vos scanners de vulnérabilités : les conteneurs construits de bas en haut réparent la visibilité
Le 19 octobre 2026, un billet du CNCF détaille le paradoxe des images distroless : en supprimant le shell et le gestionnaire de paquets, on efface aussi les métadonnées dont les scanners ont besoin, ce qui produit des faux négatifs. Si votre image minimale n’est pas auditable par Trivy, reconstruisez-la de bas en haut pour conserver les métadonnées sans réintroduire le superflu.
19 octobre 2026. Un billet publié sur The New Stack sous l’égide du CNCF décrit le « trou de visibilité distroless ». 2022. Le rapport Rezilion de Yotam Perkal documentait déjà les faux négatifs des scanners de conteneurs. Trivy. Le scanner qui lève des avertissements quand les métadonnées de paquets OS manquent. Pourquoi c’est important : réduire une image réduit l’attaque de surface, mais si le scanner ne peut plus prouver ce qu’elle contient, elle devient une dette de conformité.
L’anatomie du bloat des conteneurs
Longtemps, l’image complète a été la norme. Le développeur tirait une image de base embarquant un système d’exploitation entier, empilait son code par-dessus et expédiait le tout en production. C’était simple, et c’était un problème de sécurité massif.
Ces images embarquaient un shell, un gestionnaire de paquets et des dizaines d’utilitaires que l’application n’utilisait jamais au runtime. Chaque brique inutilisée représentait une vulnérabilité potentielle et une surface d’attaque inutilement large. Si un attaquant perçait l’application, il disposait soudain d’une boîte à outils complète pour télécharger d’autres utilitaires et escalader l’attaque.
Le trou de visibilité distroless
Pour répondre à ce problème, le mouvement distroless a émergé. L’idée était saine : dépouiller le conteneur jusqu’aux dépendances strictement nécessaires à l’exécution de l’application. Pas de shell, pas de gestionnaire de paquets, pas d’utilitaires superflus.
La surface d’attaque a bien diminué, mais à un coût opérationnel élevé. Créer une image distroless est complexe, fragile et sujet aux erreurs. À force d’élaguer agressivement, on supprime souvent les métadonnées de paquets — le manifeste de ce qui est réellement installé.
La conséquence involontaire porte un nom : le « distroless security gap ». Ce n’est pas théorique. Trivy lève des avertissements explicites quand les métadonnées de paquets OS sont absentes, et le rapport Rezilion de 2022 montrait que les scanners souffrent de faux négatifs importants — incapables de détecter des vulnérabilités actives faute de contexte. Chainguard a fait la même observation : si un scanner ne peut pas collecter les métadonnées complètes, le résultat ne reflète pas le contenu réel de l’image.
Entre l’image complète et l’image distroless, le choix devient imparfait : des conteneurs gonflés à la surface d’attaque large, ou des conteneurs minimaux que l’on ne peut pas auditer.
Trois stations : Slice, Build, Run
Il existe une troisième voie : au lieu de partir d’une grosse image pour la tailler, on construit le conteneur de bas en haut, en n’incluant que les éléments exacts dont on a besoin. Comme on assemble au lieu d’élaguer, les métadonnées restent intactes. Dans l’écosystème open source, cette génération d’images OCI minimales et auditables est parfois appelée « rocks ».
La construction se déroule comme une chaîne à trois postes.
Poste 1 — le découpage de précision. Le conteneur démarre littéralement vide. Avec un outil comme Chisel, on découpe des paquets Linux de confiance — par exemple ceux des archives Ubuntu — en tranches granulaires. On ne tire pas le paquet entier, seulement les « slices » dont l’application a besoin. Les slices proviennent d’archives curées, ce qui préserve la chaîne d’approvisionnement, et leurs métadonnées restent disponibles pour le scanner.
Poste 2 — la construction déclarative. Historiquement, on assemble les conteneurs avec des Dockerfile impératifs, où l’ordre des commandes compte et où le cache de couches crée du bloat et de la fragilité. La construction de bas en haut remplace cela par du déclaratif : avec un outil comme Rockcraft, le développeur écrit un fichier YAML décrivant l’application et ses besoins. L’outil récupère la source, tire les slices demandées, compile et produit une image OCI standard. L’expérience passe de « scripter une build » à « déclarer un état ».
name: chiseled-python
base: bare
build-base: [email protected]
version: "3.14"
parts:
install-python:
plugin: nil
stage-packages:
- base-files_release-info
- python3_corePoste 3 — apprivoiser le PID 1 au runtime. Dernière difficulté des conteneurs minimaux : la gestion des processus. Dans un système d’exploitation classique, l’OS s’en charge. Dans un conteneur, si l’application engendre des processus fils qui meurent, ils laissent des zombies qui s’accumulent jusqu’au crash. Les images traditionnelles embarquent un gestionnaire de processus ; les distroless le suppriment souvent. Pour stabiliser sans réintroduire le bloat, les conteneurs de bas en haut utilisent un gestionnaire de service minuscule comme Pebble, qui tourne en PID 1 et récolte les zombies.
Ce qu’il faut vérifier avant d’adopter
Le billet du CNCF est signé d’une responsable produit de Canonical, et les trois outils cités — Chisel, Rockcraft, Pebble — sont des projets de cet éditeur. Le propos est donc une démonstration autant qu’une analyse. La thèse centrale reste néanmoins valable indépendamment du vendeur : le problème n’est pas le minimalisme, c’est la perte de métadonnées qui l’accompagne.
D’autres voies aboutissent au même résultat. Chainguard assemble ses images Wolfi avec apko, en conservant les métadonnées APK. Les images distroless de Google restent un standard pour les runtimes statiques. Alpine garde un gestionnaire de paquets minimal mais exploitable. La question de fond est la même partout : votre scanner peut-il énumérer ce que l’image contient, et ce qu’il énumère correspond-il au contenu réel ?
Comment vérifier votre image
Le test est simple à exécuter. Sur une image minimale, Trivy signale l’absence de métadonnées par un avertissement explicite ; sur une image complète, il énumère une longue liste de paquets dont l’essentiel ne tourne jamais. La bonne question n’est pas « l’image est-elle petite ? », mais « le manifeste correspond-il au contenu ? ».
trivy image --scanners vuln mon-image:tag 2>&1 | grep -i "metadata\|package"Si le scanner renvoie une liste de paquets vide alors que l’image embarque un runtime Python ou Node, c’est le symptôme du trou de visibilité : l’image est peut-être sûre, mais rien ne le prouve.
La stabilité au runtime se vérifie de la même façon. Un conteneur sans gestionnaire de PID 1 qui lance des processus fils — un serveur web qui fork, un orchestrateur qui exécute des jobs — finit par accumuler des zombies. Le symptôme est banal : des processus defunct qui s’empilent dans ps, une mémoire qui grimpe, puis un crash que personne ne rattache à l’image. Pebble, ou n’importe quel init minimal, récolte ces processus et rend le comportement déterministe.
Côté conformité, la pression vient de la réglementation. Le Cyber Resilience Act européen et les audits de type SOC 2 ou ISO 27001 exigent de pouvoir lister les composants logiciels d’un système. Une image minimale qui résiste au scanner transforme une exigence de documentation en un échec d’audit — non pas parce que l’image est vulnérable, mais parce qu’on ne peut pas démontrer qu’elle ne l’est pas.
En pratique, cette visibilité se matérialise par une SBOM (Software Bill of Materials) que le scanner croise avec les bases de vulnérabilités. Une image de bas en haut produit cette SBOM nativement, parce que chaque slice est tracé depuis l’archive source jusqu’au runtime — là où une image élaguée à la main la perd en route. Le gain opérationnel n’est pas abstrait : quand une CVE tombe, l’équipe qui sait énumérer ses images corrige en quelques heures ; celle qui ne le sait pas passe des jours à deviner ce qu’elle exécute.
Verdict
Si votre image minimale lève des avertissements Trivy sur les métadonnées manquantes, traitez cela comme un blocage, pas comme un bruit : une image que l’on ne peut pas scanner est une dette de conformité qui se paiera à l’audit. Si vous construisez des images de production pour des runtimes interprétés, testez une construction de bas en haut — Chisel et Rockcraft côté Ubuntu, apko côté Chainguard — pour conserver la visibilité sans réintroduire de shell. Si vous gérez une flotte hétérogène, imposez une règle simple : toute image doit être auditable par votre scanner, sinon elle ne passe pas la porte de production.