Podman 6.0.0 est disponible depuis fin juin 2026, avec un billet de présentation publié début juillet. C’est une version majeure avec plusieurs suppressions de composants historiques : fin du support cgroups v1, retrait de slirp4netns et iptables, abandon de BoltDB pour SQLite, et refonte du parsing des fichiers de configuration.
Si vous utilisez Podman en production ou dans des pipelines CI, cette montée de version demande une vraie préparation. Ce n’est pas une simple mise à jour. Plusieurs changements peuvent rendre une installation inutilisable si la migration n’est pas anticipée.
Le tag latest est confortable.
On écrit un compose.yml, on lance docker compose up -d, et le service démarre. Pas besoin de choisir une version de PostgreSQL, Redis, Traefik, Gitea, Vaultwarden ou n’importe quelle application auto-hébergée.
Le problème, c’est que latest ne veut pas dire “dernière version stable adaptée à mon environnement”. Ça veut seulement dire : “ce tag pointe vers quelque chose dans le registre au moment où Docker le résout”.
Ce quelque chose peut changer sans que votre fichier Compose change.
Pour une stack de test, ce n’est pas très grave. Pour une base de données, un reverse proxy exposé, un service d’authentification ou une application avec des volumes persistants, c’est une mauvaise convention d’exploitation.
Le vrai sujet n’est pas Docker. C’est la reproductibilité.
Le 19 mars 2026, un groupe identifié comme TeamPCP a publié une version malveillante de Trivy, le scanner de vulnérabilités le plus utilisé du monde conteneurisé.
L’attaque est exemplaire dans sa mécanique.
TeamPCP a compromis le compte aqua-bot qui gère les releases de Trivy. Avec ce token, ils ont poussé un commit qui remplaçait actions/checkout par un fork malveillant, téléchargeant du code depuis un domaine typosquatté. Le flag --skip=validate de goreleaser était activé pour contourner la validation.
En quelques minutes, 76 des 77 tags de version de trivy-action étaient force-pushés vers des commits infectés. Les 7 tags de setup-trivy étaient tous remplacés.
Le payload était un credential stealer : dump de la mémoire du runner GitHub via /proc/<pid>/mem, sweep de 50+ chemins pour SSH keys, tokens AWS/GCP/Azure, secrets Kubernetes, Docker configs, fichiers .env, identifiants de base de données, wallets crypto. Les données étaient chiffrées en AES-256-CBC avec RSA-4096 et exfiltrées vers un serveur C2.
Trois jours plus tard, des images Docker Hub v0.69.5 et v0.69.6 arrivaient avec le même payload. Et un ver npm, CanisterWorm, se propageait via le paquet containers-check.
Aqua Security a détecté l’intrusion initiale fin février 2026 et avait rotationné des credentials. Mais la rotation n’était pas atomique. TeamPCP a gardé un accès résiduel via des tokens non révoqués.
Le plus frappant n’est pas la sophistication. C’est la banalité du point d’entrée : un token CI mal rotationné. Et la confiance qu’on accorde à un outil qui est censé améliorer la sécurité.
