Skip to main content

31 % ne suivent pas les dépendances des applications et 38 % ne suivent que les dépendances directes

Écrit par
DevSecOps Assets blog feature

28 janvier 2020

0 minutes de lecture

Nous avons récemment mené une étude sur l’adoption du DevOps et du DevSecOps. Dans cet article, nous examinons le niveau de préparation des organisations à l’adoption du DevSecOps, l’incidence de la maturité DevOps sur l’intégration de la sécurité, ainsi que les enseignements tirés de la posture de sécurité des équipes ayant adopté le DevOps.

Télécharger le PDF DevSecOps Insights 2020


Préparation des organisations à l’adoption du DevSecOps

En examinant la façon dont les ingénieurs auditent leurs bases de code, nous constatons une forte adoption des outils de sécurité automatisés, selon le rapport Snyk State of Open Source Security 2019 : 65 % des répondants le confirment. Il est également important de souligner que, même lorsqu’ils utilisent des outils de sécurité automatisés, 79 % des répondants continuent de réaliser des revues de code axées sur la sécurité.

Graphique à barres intitulé « Comment auditez-vous votre code ? » indiquant 79 % pour les revues manuelles, 65 % pour les tests de sécurité automatisés et le reste pour d’autres méthodes.

En adoptant des outils de sécurité automatisés, les équipes reconnaissent aussi que leur intégration dans un pipeline CI peut allonger la durée des builds, nuire à l’expérience des développeurs et ralentir la boucle de retour d’information.

Nous avons constaté que 57 % des répondants recherchent les vulnérabilités connues dans leurs dépendances open source, tandis qu’une proportion nettement plus faible effectue des tests statiques de sécurité des applications (SAST).

Graphique en barres indiquant si des tests de sécurité automatisés sont intégrés aux pipelines d’intégration continue ; les résultats vont de 14 % à 57 %.

Cela s’explique souvent par la longue durée d’exécution de ce type de test de sécurité, ainsi que par le nombre élevé de faux positifs qu’il génère et qui nécessitent ensuite une vérification manuelle.

Un peu plus de la moitié des répondants ont confirmé rechercher les vulnérabilités connues dans les dépendances open source de leurs applications, mais seulement 14 % effectuent un test similaire sur les images de conteneurs dans le cadre d’un pipeline d’intégration continue. Se pourrait-il que les répondants ignorent l’existence des outils de sécurité qui leur permettraient de combler cette lacune ? Autre possibilité : avec la plupart des outils de sécurité, vous recevez uniquement un rapport sur les vulnérabilités présentes dans l’image de conteneur, et c’est à vous qu’il revient de résoudre le problème.

Tableau de bord de sécurité des images Docker présentant des recommandations de mise à niveau des images de base, le nombre de vulnérabilités et leur niveau de gravité

À titre de comparaison, Snyk Container fournit des recommandations concrètes sous forme d’images de conteneurs alternatives qui, une fois utilisées, réduisent le nombre de vulnérabilités et limitent l’exposition globale aux risques de sécurité.

Remplacer l’image de base d’un conteneur Docker est une opération simple qui offre un excellent retour sur investissement en matière de sécurité. En effet, d’après les analyses effectuées par les utilisateurs de Snyk, le rapport Snyk State of Open Source Security indique que 44 % des images Docker analysées présentaient des vulnérabilités connues, alors qu’il existait des images de base plus récentes et plus sûres.

La sécurité des conteneurs ne se limite pas aux images de conteneurs Docker. Elle concerne également Kubernetes, où les charts Helm peuvent présenter de véritables risques de sécurité sous la forme de vulnérabilités. Le rapport Snyk 2019 Territoires inexplorés : l’histoire méconnue de la sécurité des charts Helm a révélé plusieurs risques dans ce domaine :

  • 68 % des charts Helm stables contiennent une image présentant une vulnérabilité de gravité élevée.

  • La mise à jour vers les dernières images publiées réduit le nombre de vulnérabilités dans 64 % des charts Helm stables.

  • 6 images (sur un total de 416) représentent la moitié des occurrences de vulnérabilités.

Lorsque la sécurité concerne l’application elle-même ou son vecteur de déploiement — par exemple, les images de conteneurs utilisées pour déployer l’application — nous avons constaté que les développeurs jouent un rôle clé et assument la responsabilité de la sécurité de leur application. Qu’en est-il de la responsabilité de la sécurité de l’infrastructure ? Étonnamment, dans un environnement DevSecOps, toutes les parties prenantes contribuent presque à parts égales à la sécurité de l’infrastructure.

Découvrez notre nouveau rapport sur la sécurité de l’open source 2020. Ce rapport examine les enjeux de sécurité de l’open source en 2020, ainsi que les tendances des vulnérabilités dans les packages et les images de conteneurs.


Poursuivez votre lecture avec notre étude DevSecOps Insights 2020 :

Télécharger le PDF DevSecOps Insights 2020