Publié le 10 février 2026 20h33. La quête d’images de conteneurs exemptes de vulnérabilités connues (CVE) se heurte aux limites des modèles de publication des logiciels en amont, poussant certains fournisseurs à adopter des approches plus radicales pour garantir la sécurité de leurs environnements conteneurisés.
- Des entreprises comme Chainguard reconstruisent les conteneurs et leurs bibliothèques à partir des sources à chaque modification en amont, pour maintenir un état « zéro CVE ».
- Docker propose une approche différente avec ses images renforcées, axée sur la réduction de la surface d’attaque et l’utilisation de SBOM (Software Bill of Materials).
- Des experts soulignent que la gestion des CVE est imparfaite et que la simple absence de CVE ne garantit pas une sécurité totale.
La demande d’images de conteneurs sans vulnérabilités connues s’intensifie, mais atteindre cet objectif s’avère complexe. Les fournisseurs se rendent compte que s’appuyer uniquement sur les distributions Linux traditionnelles et leurs correctifs de sécurité peut entraîner un décalage entre la découverte d’une faille et sa résolution effective. Cette situation est particulièrement problématique dans un contexte où le nombre de vulnérabilités signalées augmente de façon exponentielle.
Chainguard, un acteur majeur dans la fourniture d’images de conteneurs sécurisées, a développé une solution basée sur son logiciel Factory 2.0 et son approche open source DriftlessAF. L’entreprise reconstruit les conteneurs et leurs bibliothèques directement à partir des sources chaque fois qu’une modification est détectée dans les projets en amont. Chaque construction génère une sortie reproductible, couvrant les builds initiaux, les reconstructions basées sur les dépendances et les vulnérabilités, ainsi que les modifications d’outils. L’utilisation de SBOM et de signatures numériques renforce la sécurité par défaut.
Docker propose une alternative avec ses Images renforcées Docker (DHI), qui s’appuient sur Alpine Linux et Debian Linux. Ces images offrent une surface d’attaque réduite, des valeurs par défaut non root, des SBOM et une provenance cryptographique.
Selon Sam Katzen, responsable du marketing produit chez Chainguard, les cycles de publication plus lents et les longues chaînes de dépendances des mainteneurs de distributions en amont ne permettent pas de suivre le rythme actuel de découverte des vulnérabilités.
« Les fournisseurs qui s’appuient sur des distributions comme Debian ou Alpine se retrouvent dans une impasse : ils héritent de vulnérabilités qu’ils n’ont pas créées et qu’ils ne peuvent pas facilement contrôler. »
Sam Katzen, responsable du marketing produit chez Chainguard
En approfondissant, Katzen explique que les images DHI, construites sur Debian, héritent de l’ensemble des paquets, de la posture de sécurité et du calendrier de publication de Debian. En pratique, de nombreuses entrées Vulnerability Exploitability eXchange (VEX) de DHI reflètent l’état des avis de sécurité de Debian (DSA). L’équipe de sécurité de Debian utilise l’indicateur « no-DSA » pour les problèmes qui ne justifient pas un correctif immédiat ou une reconstruction hors cycle, souvent parce qu’ils sont considérés comme mineurs ou difficiles à exploiter.
Cependant, Katzen estime que cette approche peut ne pas être suffisante pour tous. Il souligne que de nombreux CVE signalés sans DSA sont en réalité inexploitables, mais que considérer l’indicateur « no-DSA » comme une preuve d’absence de vulnérabilité peut induire en erreur les utilisateurs qui s’appuient sur des scanners connectés aux données VEX.
Il met en évidence trois exemples concrets : CVE‑2026‑0861 (glibc), CVE‑2026‑0915 (glibc) et CVE‑2025‑6141 (ncurses). Dans ces cas, des correctifs existent en amont, mais n’ont pas encore été intégrés dans Debian, et donc pas dans DHI. Les scanners, en se basant sur les données VEX de DHI, peuvent alors signaler ces images comme non affectées, alors qu’elles le sont techniquement.
Chainguard préconise une approche où le tri et la correction des CVE sont effectués directement à partir des sources, sans attendre les calendriers de publication des distributions en amont. Son catalogue de plus de 2 000 images minimales est continuellement reconstruit pour maintenir un état « zéro CVE », tout en assurant la visibilité de la chaîne d’approvisionnement, les SBOM et la gestion explicite des CVE.
Le débat soulève également une question fondamentale : le système CVE lui-même est-il adapté ? Des organisations comme la Cloud Security Alliance et SecOps Solution estiment que les CVE sont indépendants du contexte et ne reflètent pas nécessairement le risque réel pour un déploiement spécifique. De plus, une étude révèle qu’un tiers des CVE pourraient être invalides. Selon Aram Hovsepyan, PDG de Codific, la création de CVE peut être motivée par des considérations de carrière et peut être facilement manipulée, voire générée artificiellement par l’IA, comme l’a récemment souligné Daniel Stenberg, le créateur de cURL.
En conclusion, bien que les CVE soient des éléments précieux, ils ne doivent pas constituer la base d’une stratégie de sécurité complète. Une compréhension approfondie des risques, basée sur la modélisation des menaces et le tri contextuel, est essentielle. La quête d’images de conteneurs sécurisées est un processus complexe qui nécessite une approche nuancée et une évaluation continue des risques.