Je ne touche plus beaucoup à AWX ces temps-ci. C'est une conversation sur le salon Devoxx qui a rallumé ma curiosité : au détour d'une discussion, quelqu'un me raconte qu'il fait toujours tourner AWX en production, et glisse presque en passant que le projet ne sort plus de version depuis un bon moment. La remarque m'a titillé.
De retour au calme, j'ai voulu voir ce que ça donnait concrètement. J'ai récupéré la dernière image officielle et je l'ai passée au scanner de vulnérabilités : 45 CVE, dont 3 critiques. Toutes logées dans une version qui n'a pas bougé depuis deux ans. Ce n'est pas un bug d'AWX, c'est la conséquence d'une décision passée presque inaperçue : depuis l'été 2024, le projet ne publie plus de release.
Si vous faites tourner AWX en production ou en homelab, vous êtes peut-être concerné sans le savoir. J'ai creusé la situation, testé les options concrètes, et je vous donne ici les chiffres et la solution que je retiens.
Ce qui s'est passé : plus de release depuis juillet 2024
La dernière version publiée d'AWX est la 24.6.1, sortie le 2 juillet 2024. Depuis, plus rien : ni tag, ni image officielle sur le registre. Ce n'est pas un abandon. L'équipe a entamé une refonte profonde vers une architecture découplée (l'interface, l'inventaire et les types de credentials sont extraits en services séparés) et a basculé du versionnement sémantique vers du CalVer. Pendant ce chantier, les releases sont gelées.
Le souci, c'est le silence qui accompagne ce gel. Une issue GitHub demandant la date de la prochaine release est restée ouverte des mois sans réponse ferme. Un membre de l'équipe communauté a fini par reconnaître publiquement que le manque de communication n'était pas terrible. En clair : le développement continue à vive allure sur la branche devel, mais plus aucun livrable n'atteint les utilisateurs.
Le vrai problème : une image figée est un stock de CVE
Une image conteneur ne vieillit pas bien. Son système de base, ses paquets Python, ses bibliothèques sont figés au jour du build. Chaque vulnérabilité découverte ensuite dans ces composants s'y accumule, sans jamais être corrigée. Deux ans, c'est très long à l'échelle des CVE.
La mesure est reproductible en une ligne. J'ai passé l'image quay.io/ansible/awx:24.6.1 au crible de Trivy, en ne gardant que les sévérités critiques et hautes :
trivy image --severity CRITICAL,HIGH quay.io/ansible/awx:24.6.1Le verdict est sans appel : 3 vulnérabilités critiques et 42 hautes, soit 45 CVE uniques, presque toutes dans les dépendances Python gelées à mi-2024. Faire tourner cette image aujourd'hui, c'est exposer volontairement une surface d'attaque connue et non corrigée.
Les deux fausses bonnes idées
Face à ce constat, deux réflexes viennent naturellement. Aucun des deux ne tient.
Rester sur 24.6.1 en assumant. C'est le choix par défaut de ceux qui ne savent pas que le projet est gelé. On vient de voir le prix : 45 CVE dont 3 critiques, et ça empire chaque mois.
Builder l'image soi-même depuis devel. L'idée est séduisante : le code récent a des dépendances plus fraîches. J'ai voulu la vérifier plutôt que d'y croire. J'ai cloné le dépôt, figé un commit précis (pour rester reproductible), et lancé le build officiel de l'image de production :
make awx-kube-buildL'image sort correctement, le code se charge sans erreur. Côté sécurité, elle tombe à 0 critique et 27 CVE hautes : mieux que l'image figée, forcément. Mais deux problèmes demeurent. D'abord, devel est en pleine refonte : ses propres mainteneurs préviennent qu'une partie de l'application peut casser sans prévenir. Ensuite, cette image est périmée le lendemain : devel bouge tous les jours, il faudrait la reconstruire en boucle et la tester à chaque fois. C'est un travail d'intégration continue à assumer, pas une solution clé en main.
La solution que je retiens : Ascender
C'est en cherchant comment d'autres s'en sortent que je suis tombé sur Ascender, un fork d'AWX maintenu par Ctrl IQ (les gens derrière Rocky Linux). Le pari est exactement celui qui manque à AWX : continuer à publier des versions stables et patchées.
Et ce n'est pas un projet dormant. Les releases s'enchaînent à un rythme mensuel (la 25.4.0 date de juin 2026), et chaque note de version liste explicitement des correctifs de CVE dans les dépendances (Django, cryptography, aiohttp et compagnie). J'ai passé la dernière image au même scanner, dans les mêmes conditions :
trivy image --severity CRITICAL,HIGH ghcr.io/ctrliq/ascender:25.4.0Résultat : 0 critique et 22 CVE hautes. Non seulement Ascender élimine les trois vulnérabilités critiques de l'image figée, mais il fait mieux que ma propre image buildée depuis devel (22 contre 27). La leçon est contre-intuitive mais nette : un fork qui met activement ses dépendances à jour bat le fait de builder soi-même du code brut.
Voici les trois voies côte à côte, sur des images de taille comparable :
| Image | Critiques | CVE hautes (uniques) | Maintenue |
|---|---|---|---|
| AWX 24.6.1 (officielle figée) | 3 | 45 | non |
Self-build depuis devel | 0 | 27 | à votre charge |
| Ascender 25.4.0 | 0 | 22 | oui, mensuel |
Ascender fournit aussi son propre installeur (VM unique en k3s, ou déploiement sur les principaux Kubernetes managés) et un chemin de migration depuis AWX. Pour qui veut un AWX récent, sécurisé et stable sans transformer sa PIC en projet à temps plein, c'est la réponse la plus directe.
Quand builder soi-même garde du sens
Je ne jette pas le self-build pour autant. Il reste pertinent dans des cas précis : un environnement air-gap où vous devez maîtriser chaque couche de l'image, une chaîne d'intégration interne qui reconstruit et scanne automatiquement à chaque changement, un besoin d'audit de supply chain de bout en bout. Dans ces situations, produire et scanner sa propre image est un vrai geste de sécurité. Mais il faut alors pinner un commit, tester avant de promouvoir, et rebuild régulièrement. C'est un engagement, pas un raccourci.
Et si vous avez le budget et un besoin de support contractuel, AAP (Ansible Automation Platform) reste la voie commerciale de Red Hat : c'est la version supportée, pensée pour l'entreprise, là où AWX a toujours été un projet amont mouvant.
Choisir une image ne suffit pas : mitiger en continu
Un point que la discussion à Devoxx m'a rappelé : choisir la bonne base n'est qu'un début. Même l'image Ascender, la plus saine des trois, garde 22 vulnérabilités hautes. Aucune image conteneur n'est propre à 100 %, et surtout, aucune ne le reste : de nouvelles CVE tombent chaque semaine sur les dépendances.
La sécurité d'une image n'est pas un état, c'est un processus. Un scan Trivy donne une photo à l'instant T ; pour le suivi dans la durée, une plateforme comme Dependency-Track est mieux taillée. On lui pousse le SBOM de l'image (au format CycloneDX, produit par Trivy ou Syft), et elle ré-évalue en continu ses composants : dès qu'une nouvelle CVE touche une brique déjà déployée, elle alerte, sans qu'on ait à relancer un scan. À cela s'ajoutent deux réflexes simples : suivre les mises à jour de la solution retenue et re-déployer régulièrement. Sur chaque nouvelle version, je m'accorde une période de quarantaine, le temps de vérifier qu'elle n'introduit ni régression ni nouveau problème, sauf exploitabilité haute : dans ce cas, on patche sans attendre. L'important reste de ne jamais laisser une image se figer, le piège d'origine.
Et le scan ne dispense pas des mitigations classiques : ne pas exposer l'interface d'AWX en direct sur Internet, appliquer le moindre privilège, isoler le réseau, patcher l'hôte. Une image plus fraîche réduit la surface d'attaque, elle ne la supprime pas.
À retenir
- AWX ne publie plus de release depuis le 2 juillet 2024, le temps d'une refonte d'architecture et d'un passage à CalVer.
- L'image officielle 24.6.1 accumule 45 CVE (dont 3 critiques) : la laisser en production est un risque qui grossit chaque mois.
- Builder depuis
develréduit les CVE (0 critique, 27 hautes) mais expose à l'instabilité de la refonte et à une maintenance permanente. - Ascender, le fork maintenu par Ctrl IQ, offre 0 critique et 22 CVE, des releases mensuelles patchées et un installeur : c'est la solution que je recommande par défaut.
- Le self-build ne se justifie que pour l'air-gap, la CI interne ou l'audit supply chain ; AAP couvre le besoin de support commercial.
- Contre-intuitif mais mesuré : un fork qui met ses dépendances à jour bat le self-build de code brut.
- Choisir une image saine ne suffit pas : il faut mitiger en continu (scan récurrent, mises à jour, moindre privilège) car aucune image ne reste propre.
Liens utiles
- tj-actions/changed-files, l'incident supply chain de mars 2025 : un rappel de ce que coûte une brique CI/CD non maîtrisée.
- Chainguard Actions, durcir sa supply chain CI/CD : la même logique appliquée aux GitHub Actions.
- Les Execution Environments Ansible : construire et sécuriser ses propres images d'exécution.
- Dependency-Track : suivre les CVE de vos images dans la durée à partir de leur SBOM.