La sécurité des conteneurs a passé des années à fonctionner selon un cycle familier : analyser, identifier les vulnérabilités, appliquer des correctifs et répéter. Mais à mesure que le volume de vulnérabilités augmente et que les exigences réglementaires s’inscrivent de plus en plus profondément dans les flux de livraison de logiciels, ce modèle devient de plus en plus difficile à maintenir pour les équipes d’ingénierie.
L'étude 2026 de TheCUBE Research a révélé que 58 % des personnes interrogées utilisent l'analyse des vulnérabilités comme contrôle de sécurité de la chaîne d'approvisionnement logicielle. Dans le même temps, 47 % identifient la sécurité de la chaîne d'approvisionnement logicielle comme une priorité absolue en matière d'investissement, ce qui indique que les organisations reconnaissent le problème mais qu'elles dépendent encore fortement de la détection des vulnérabilités après leur entrée dans la pile logicielle.
Dans le dernier épisode du podcast AppDevANGLE de CUBE Research, j'ai parlé avec Sudeep Goswami, PDG de Traefik Labs, d'un approche alternative: réduire les logiciels inclus dans l'infrastructure des conteneurs afin qu'il y ait moins de vulnérabilités en premier lieu. Traefik poursuit cette stratégie via Distro Zero, une approche conçue pour supprimer les composants et les dépendances du système d'exploitation qui ne sont pas nécessaires à l'exécution de l'application.
« Le mieux qu'un scanner puisse faire est de vous informer plus rapidement d'un problème que vous devez encore résoudre », a déclaré Goswami. « Vous pouvez acheter une vadrouille plus rapide, mais quelqu’un doit s’arrêter et se demander : d’où vient l’eau en premier lieu ?
Réduire les vulnérabilités avant qu’elles n’atteignent le scanner
Les scanners de vulnérabilités restent un élément important de la sécurité de la chaîne d'approvisionnement logicielle, mais l'analyse ne modifie pas la taille de la surface d'attaque sous-jacente.
Cette distinction devient de plus en plus importante à mesure que les volumes de vulnérabilité augmentent. Chaque dépendance regroupée dans un conteneur peut introduire un autre composant qui doit être analysé, suivi, corrigé et documenté.
L'approche de Traefik commence par se demander si tous ces composants doivent exister dans l'artefact de production.
Les binaires d'applications sont traditionnellement regroupés aux côtés des bibliothèques du système d'exploitation, des shells, des gestionnaires de packages, des utilitaires et d'autres composants de support. Selon Goswami, la plupart des vulnérabilités rencontrées par Traefik proviennent du logiciel environnant plutôt que du binaire de l'application lui-même.
« Ce que nous constatons, c'est que le facteur bruit est énorme », a-t-il déclaré. « C'est presque comme cette analogie 80/20… 80 % des CVE qui sortent sont du bruit, et les 20 % sont ce qui est vraiment pertinent. »
Distro Zero tente de supprimer cette surface de dépendance environnante et de fournir l'application sous forme de binaire autonome. L’objectif n’est pas de rendre obsolète l’analyse des vulnérabilités, mais de réduire ce que les scanners et les équipes de sécurité doivent gérer.
Sans distribution ne signifie pas sans dépendance
La distinction entre les conteneurs traditionnels sans distribution et ce que Traefik appelle Distro Zero est importante.
Les images de conteneurs sans distribution réduisent déjà la surface d'attaque en supprimant des outils tels que les shells, les gestionnaires de packages et les utilitaires Linux courants. Cela peut rendre plus difficile pour un attaquant d’opérer à l’intérieur d’un conteneur compromis.
Mais ces images peuvent toujours dépendre de composants tels que les bibliothèques C, les éditeurs de liens dynamiques et les bibliothèques cryptographiques. Ces dépendances font toujours partie de l'environnement d'exécution et peuvent introduire leurs propres vulnérabilités.
« Fondamentalement, Distroless supprime la boîte à outils qu'un attaquant pourrait utiliser une fois entré dans un environnement », a déclaré Goswami. « Cela ne supprime pas la base de code ou l'ensemble des éléments qui leur permettent d'entrer en premier lieu. »
Pour les équipes d’ingénierie de plate-forme et de sécurité des applications, cela change la conversation de la simple réduction des outils à l’intérieur d’une image à la compréhension de la chaîne complète de dépendances d’exécution.
Cela reflète également l’attention croissante portée à la sécurité de la mémoire. Goswami a souligné les conseils encourageant les organisations à adopter des langages sécurisés en mémoire lorsque cela est possible, car la sécurité de la chaîne d'approvisionnement logicielle se concentre de plus en plus sur la prévention de classes entières de vulnérabilités plutôt que sur la détection continue d'instances individuelles.
La conformité entre dans le pipeline de livraison de logiciels
La réduction de la surface d'attaque devient de plus en plus pertinente à mesure que les exigences réglementaires recoupent de plus en plus les flux de travail d'ingénierie. Cinquante-quatre pour cent des organisations citent les cadres du NIST comme une pression réglementaire affectant l'ingénierie des versions, tandis que 46 % citent la loi de l'Union européenne sur la cyber-résilience.
Cela signifie que la conformité ne peut plus rester isolée au sein des organisations de sécurité et juridiques. Les développeurs et les équipes de plateforme doivent de plus en plus tenir compte des exigences cryptographiques, des dépendances logicielles, de la gestion des vulnérabilités et de la provenance des artefacts dans le cadre de la CI/CD.
Goswami a spécifiquement cité la transition vers les exigences FIPS 140-3 et l'ARC de l'UE comme exemples de la raison pour laquelle les entreprises doivent penser au-delà de la résolution indépendante des exigences de conformité individuelles.
Plutôt que de sélectionner une infrastructure distincte pour la conformité cryptographique, la réduction des vulnérabilités et d’autres exigences réglementaires, la plus grande opportunité architecturale consiste à consolider ces exigences lorsque cela est possible.
« S'il y avait un moyen de commencer avec le bon framework Distro Zero, qui assure également la conformité FIPS 140-3 et vous permet de gérer d'autres directives réglementaires comme l'EU CRA, ce serait un excellent choix architectural », a déclaré Goswami.
Le problème sous-jacent est la complexité opérationnelle. Chaque produit de sécurité, dépendance d'exécution et artefact d'infrastructure supplémentaire crée un autre cycle de vie que les équipes d'ingénierie et de sécurité doivent gérer.
Le coût opérationnel caché des artefacts logiciels
La complexité opérationnelle devient particulièrement visible à travers les nomenclatures logicielles.
Chaque artefact supplémentaire introduit son propre SBOM, son inventaire des dépendances, son processus de gestion des vulnérabilités et potentiellement un autre examen de sécurité ou de conformité. À mesure que les entreprises ajoutent des passerelles API, des passerelles IA et une infrastructure Model Context Protocol, ces exigences peuvent se multiplier rapidement.
C'est là que l'architecture plus large de Traefik devient pertinente. La société consolide les capacités d'entrée, de passerelle API, de passerelle IA et de passerelle MCP dans un binaire commun plutôt que de les traiter comme des produits d'infrastructure distincts.
Goswami a décrit un modèle dans lequel les organisations déploient et certifient le binaire une fois, puis activent des fonctionnalités supplémentaires via des licences à mesure que leur architecture évolue.
« Et s'il existait un binaire unifié que vous déployez une fois, que vous certifiez une fois, que vous comprenez le SBOM, toutes les dépendances initialement ? » dit-il. « Au fur et à mesure que vous parcourez ce parcours de capacités incrémentielles, cela devient simplement un déverrouillage de licence plutôt qu'une mise à niveau binaire. »
Pour les équipes de plateforme d’entreprise, l’avantage potentiel ne réside pas simplement dans le fait d’avoir moins de binaires. Cela réduit le nombre d’examens de sécurité, d’inventaires de dépendances et de processus opérationnels qui les accompagnent.
L’IA redéfinit la passerelle
Le timing est important car le rôle des passerelles d’applications s’étend également. Historiquement, les contrôleurs d'entrée et les passerelles API servaient de porte d'entrée aux applications et aux API. L'IA introduit deux types de trafic supplémentaires : les modèles et les agents.
Les organisations commencent à déployer des passerelles IA pour les interactions de modèles et des passerelles MCP pour les connexions entre les agents, les outils et les données d'entreprise. Chaque nouvelle couche crée un autre point potentiel d’application de la sécurité et un autre composant d’infrastructure à exploiter.
« Traditionnellement, il s'agissait d'API, mais maintenant vous ajoutez deux personnages supplémentaires à cette pièce, qui sont des agents et des modèles », a déclaré Goswami.
Cette évolution rend la consolidation de plus en plus pertinente. Plutôt que de créer des piles de passerelles distinctes pour les API, les modèles et les agents, les organisations peuvent rechercher des couches de politique et de sécurité communes capables de gérer les trois.
Cela élargit également la signification de la sécurité de la chaîne d’approvisionnement logicielle. La préoccupation n’est plus seulement de savoir quels packages sont regroupés dans une application. Les équipes doivent réfléchir à l'infrastructure à travers laquelle les API, les modèles d'IA et les agents autonomes communiquent.
L'essentiel
Le scanner de vulnérabilités ne disparaîtra pas. Mais il devient de plus en plus difficile de compter sur l'analyse comme principale réponse à la sécurité de la chaîne d'approvisionnement logicielle à mesure que les dépendances, les exigences réglementaires et les architectures d'applications augmentent.
La réduction de la surface d'attaque offre une stratégie complémentaire : supprimer les composants inutiles avant qu'ils ne deviennent des vulnérabilités que les équipes de sécurité doivent découvrir, prioriser et corriger.
Pour les développeurs et les équipes de plateforme, la leçon la plus importante s’étend au-delà des conteneurs. Chaque artefact de dépendance et d’infrastructure crée des obligations opérationnelles et de sécurité tout au long de son cycle de vie. À mesure que les API, les modèles et les agents convergent vers une infrastructure partagée, minimiser cette surface pourrait devenir aussi important que la surveiller.
L'approche Distro Zero de Traefik représente une tentative de déplacer le modèle de sécurité en amont, depuis la recherche plus rapide des vulnérabilités jusqu'à l'élimination des parties de la surface logicielle où ces vulnérabilités peuvent exister.
Voici la conversation complète que j'ai eue avec Sudeep Goswami, qui fait partie de la série de podcasts AppDevANGLE de CUBE Research :
