80 % des développeurs ne prennent pas en compte la sécurité de Docker

Écrit par

William Henry

17 avril 2019

0 minutes de lecture

Bienvenue dans le rapport sur la sécurité de Docker : Déplacer la sécurité de Docker plus tôt dans le cycle de développement.Ce rapport se compose de plusieurs articles :

Déplacer la sécurité de Docker plus tôt dans le cycle de développement
Les deux images de base Docker les plus populaires comptent chacune plus de 500 vulnérabilités
80 % des développeurs ne prennent pas en compte la sécurité de Docker
Prenez des mesures pour renforcer la sécurité de vos images Docker

Vous pouvez aussi télécharger notre rapport PDF soigneusement conçu, qui rassemble toutes ces informations et bien plus encore.

Responsabilité de la sécurité des conteneurs

Lorsque Docker fait partie intégrante de votre écosystème, quelqu’un doit en assumer la responsabilité. La plupart des personnes s’accordent à dire qu’il s’agit d’un effort collectif. Interrogés sur la responsabilité de la sécurité des conteneurs (avec la possibilité de choisir plusieurs réponses), la plupart des répondants estiment qu’elle incombe aux développeurs (68 %), puis aux équipes opérationnelles (39 %).

Diagramme en barres demandant qui est responsable de la sécurité des images de conteneurs : Développeurs 68 %, Opérations 39 %, Équipe de sécurité 27 %, Autres 3 %, Personne 12 %.

Même si la responsabilité de la sécurité est partagée au sein du DevOps, ou mieux encore du DevSecOps, nous constatons que la majorité estime que les développeurs jouent un rôle essentiel. C’est également ce que nous observons concernant la responsabilité de la sécurité du code applicatif. Selon le rapport sur l’état de la sécurité de l’Open Source, 81 % des répondants estiment que les développeurs doivent être responsables de la sécurité de leurs applications.

Les organisations peuvent également envisager de collaborer avec le fournisseur de confiance de leurs images de base afin de gérer certains risques de sécurité liés à leurs pipelines CI/CD. Des fournisseurs comme Red Hat proposent des images analysées et signées. Ils corrigent également rapidement les CVE concernant les images de base, ce qui permet de déclencher la reconstruction des images applicatives dans les pipelines CI/CD. Cela ne supprime pas la nécessité d’effectuer des analyses tout au long du cycle de vie DevOps, mais réduit le délai entre la présence d’images vulnérables en production et celle d’images saines. Le partage des risques avec un tiers peut contribuer à réduire le risque global.

Tester la sécurité de la couche du système d’exploitation

Malheureusement, seuls 19 % des développeurs déclarent rechercher les vulnérabilités de la couche du système d’exploitation dans leurs images Docker pendant le développement. Cela signifie que plus de 80 % des développeurs ne déplacent pas la sécurité plus tôt dans le cycle de développement pour tester leurs images ; ils découvrent donc les vulnérabilités plus tard, ce qui coûte plus cher.

De plus, la moitié des utilisateurs (50 %) n’effectuent aucune analyse de la couche du système d’exploitation de leurs images Docker. Il est important de savoir ce que contient cette couche. Utiliser des images Docker sans les vérifier présente de grands risques, car vous y introduirez inévitablement d’innombrables vulnérabilités. Vous pouvez facilement réduire ce risque en les analysant et en identifiant d’abord les vulnérabilités connues de chaque image envisagée.

Diagramme à barres horizontales indiquant quand les images Docker sont analysées pour détecter les vulnérabilités du système d’exploitation : 50 % répondent qu’elles ne le sont pas, 31 % au moment de la compilation et 19 % pendant le développement.

Un outil d’analyse d’images Docker, comme celui proposé par Snyk, permet de détecter les images vulnérables tout au long du cycle de développement. Dès le poste de travail, lorsqu’un développeur choisit une image Docker, l’analyse empêche l’introduction d’images vulnérables dans votre environnement. Répétez les analyses à chaque étape, jusqu’à la fin du pipeline CI/CD, afin d’empêcher qu’une image présentant des vulnérabilités connues soit déployée en production.

Les vulnérabilités des images sont naturellement découvertes au fil du temps ; il est donc essentiel de suivre vos images en production. Le délai médian entre la découverte d’une vulnérabilité et sa divulgation est de 2,5 ans. À l’heure actuelle, seuls 9 % des utilisateurs déclarent analyser leurs images en production. Une image était peut-être sûre lors de son déploiement, mais par la suite, plus de 90 % des développeurs ne connaîtraient pas l’état de sécurité actuel de leurs images.

Découvrir les vulnérabilités

Nous avons également demandé aux participants comment ils apprenaient qu’un conteneur qu’ils utilisent contient des vulnérabilités divulguées. 45 % ne vérifient probablement jamais. Une part non négligeable (15 %) des répondants consulte des bases de données publiques, comme celle des CVE. Gardez toutefois à l’esprit que la base de données des CVE ne représente que la partie émergée de l’iceberg. L’enregistrement d’une CVE peut prendre plusieurs semaines et de nombreuses vulnérabilités ne seront peut-être jamais répertoriées comme CVE, tout en présentant un risque majeur pour votre système.