Skip to main content

Snyk Container en 2021 : repousser toujours plus loin la sécurité des conteneurs

Écrit par
blog feature snyk container party

22 décembre 2021

0 minutes de lecture

Quel que soit l’angle, l’utilisation des conteneurs et de Kubernetes continue de progresser. Et les récentes vulnérabilités très médiatisées dont on ne prononcera pas le nom nous ont montré à quel point la sécurité des conteneurs est essentielle à un programme global de sécurité des applications. Protéger votre propre code, vos dépendances, et les services conteneurisés que vous utilisez est indispensable.

Les signes d’une adoption toujours plus rapide des conteneurs sont partout. En 2021, les clients de Snyk ont effectué plus de 130 millions de tests de conteneurs, soit 10 fois plus qu’en 2020 ! Datadog et Sysdig indiquent chacun surveiller bien plus de 1 milliard de conteneurs, et Gartner prévoit que plus de 75 % des organisations dans le monde exécuteront des applications conteneurisées en production en 2022, contre moins de 30 % l’année dernière encore.

À l’approche de la fin de l’année 2021, nous revenons sur les principales nouveautés des produits Snyk. Dans cet article, nous nous intéressons à Snyk Container.

L’utilisation de Snyk Container explose en 2021

Comme indiqué plus haut, Snyk Container a été utilisé pour plus de 130 millions de tests de conteneurs jusqu’à présent en 2021. Mais tester un conteneur n’est pas l’objectif ultime de Snyk Container : le résultat attendu, c’est de CORRIGER les problèmes des conteneurs. Voici les résultats obtenus avec Snyk Container :

  • Les utilisateurs de Snyk Container ont corrigé 56 millions de vulnérabilités en 2021.

  • Ce résultat s’appuie sur plus de 133 millions d’analyses de conteneurs portant sur plus de 2 millions d’images, qui ont permis de détecter plus de 111 millions de vulnérabilités distinctes dans les conteneurs. 

    * Le nombre de vulnérabilités est inférieur au nombre de tests, car une vulnérabilité détectée lors de plusieurs tests répétés sur une même image n’est comptabilisée qu’une seule fois.

Et il ne s’agit pas seulement de l’analyse des images dans les pipelines et les registres. Snyk Container a également surveillé 47 000 projets Kubernetes et 352 000 dépôts Git contenant des Dockerfiles.

Des améliorations de Snyk Container pensées pour les développeurs

En 2021, Snyk Container a ajouté plusieurs fonctionnalités adaptées aux flux de travail des développeurs. Notre objectif est de rendre la détection et la correction des problèmes liés aux conteneurs aussi simples et évidentes que possible, au point qu’il soit difficile de ne pas les corriger.

L’une des nouveautés les plus importantes est la possibilité d’analyser les Dockerfiles à partir des dépôts de code source et d’ouvrir des pull requests pour corriger les problèmes détectés. C’est une première pour un produit de sécurité des conteneurs. Choisir une image de base adaptée et sécurisée pour une application est un moyen relativement simple de réduire jusqu’à 90 % des vulnérabilités dans un conteneur.

Recommandations d’images de base Snyk Container comparant les mises à niveau d’images Ruby selon le nombre et la gravité des vulnérabilités, avec des options pour ouvrir des pull requests de correction.
Snyk Container analyse un Dockerfile afin de fournir des recommandations d’images de base et de créer des pull requests correctives.

Le choix de l’image parente sur laquelle s’appuyer étant si important, nous voulions que le plus grand nombre possible d’utilisateurs bénéficient des recommandations de Snyk concernant les images de base, quel que soit le moment du cycle de vie du conteneur auquel ils choisissent de lancer une analyse. Pour cela, nous avons modifié la façon dont nous détectons l’image parente d’un conteneur. À l’approche du mois de décembre, plus de 80 % des conteneurs analysés bénéficient désormais de recommandations sur les images de base, contre environ 25 % en janvier.

Graphique linéaire intitulé « Recommandations d’image parent », montrant une hausse des pourcentages, de 25 % en décembre à environ 81 % en décembre suivant.
Pourcentage de projets de conteneurs bénéficiant de recommandations automatiques de mise à niveau de l’image parente.

Fait intéressant, la logique de Snyk Container concernant les images de base repose sur les images officielles de Docker. Le taux élevé de recommandations sur les images parentes témoigne donc clairement de la popularité et de l’importance toujours croissantes de Docker dans l’univers des conteneurs.

Nous avons également présenté à SnykCon nos travaux en cours sur la prise en charge de Snyk Container dans les IDE. Associée à notre partenariat continu avec Docker, cette avancée est un excellent signe de ce qui nous attend, tandis que nous continuons à intégrer la sécurité des conteneurs toujours plus tôt dans le cycle de développement.

Améliorations des flux de travail et de l’écosystème des conteneurs

En 2021, nous avons également entrepris de résoudre certains problèmes récurrents des flux de travail reposant sur des conteneurs, qui peuvent compliquer la correction des problèmes. Nous voulions aussi étendre notre prise en charge des outils de conteneurs populaires dans un écosystème en pleine expansion.

L’une des difficultés propres aux flux de travail utilisant des conteneurs consiste à maintenir le lien entre le Dockerfile et les images qui en résultent. Les images de conteneurs ne permettent pas, par défaut, de savoir quel Dockerfile a servi à les créer. Il peut donc être difficile d’identifier les responsables d’un conteneur donné et de savoir quel Dockerfile modifier pour corriger les problèmes. Pour simplifier cela dans Snyk Container, nous avons décidé de suivre la norme OCI relative aux étiquettes de conteneurs, qui permet de relier ces deux artefacts. Si vous utilisez ces étiquettes OCI dans Snyk Container, nous pouvons automatiquement vous indiquer quelles images de conteneurs analysées avec Snyk ont été créées à partir d’un Dockerfile donné. Vous pouvez ainsi facilement associer les tests de conteneurs entre eux et accéder directement au Dockerfile à modifier.

Dans le même esprit d’adoption des normes, nous avons également ajouté la possibilité d’utiliser des normes de politiques ouvertes pour déterminer ce que Snyk surveille dans vos clusters Kubernetes. Open Policy Agent (OPA) est un plan de contrôle populaire fondé sur des politiques pour les environnements cloud natifs. Nous l’utilisons avec notre outil de surveillance Kubernetes pour vous permettre de déterminer quelles charges de travail surveiller automatiquement, et si et quand les supprimer si elles cessent de s’exécuter dans vos clusters.

Nous avons également ajouté de nouvelles intégrations avec d’autres outils populaires de l’écosystème des conteneurs :

Réduire le bruit lié aux conteneurs et enrichir les informations de sécurité

À première vue, il peut sembler contradictoire d’ajouter davantage d’informations de sécurité tout en réduisant le bruit généré par les vulnérabilités des conteneurs. Pourtant, nous y sommes parvenus en 2021 avec Snyk Container.

Pour réduire le bruit généré par les alertes de sécurité liées aux conteneurs et vous aider à vous concentrer sur les vulnérabilités les plus importantes à corriger, nous avons ajouté des données sur les tendances des réseaux sociaux à nos informations sur les vulnérabilités. Une hausse des discussions sur les réseaux sociaux peut signaler une activité malveillante liée à une vulnérabilité et s’avérer très utile pour établir les priorités.

Nous avons également amélioré les capacités de gestion des politiques de sécurité de la plateforme Snyk, en proposant de nouveaux moyens d’accorder plus ou moins d’importance aux vulnérabilités à l’échelle d’une organisation. Par exemple, vous pourriez vouloir augmenter la priorité des vulnérabilités liées à la mémoire pour les applications exécutées en production. L’interface de gestion des politiques de sécurité de Snyk vous permet de définir une règle telle que :

  • Toutes les applications dotées de l’attribut ou de l’étiquette Production…

  • et présentant des vulnérabilités exploitant soit CWE 125 (lecture hors limites), soit CWE 787 (écriture hors limites)…

  • passent au niveau de gravité Critique

Formulaire de stratégie de sécurité Snyk pour les projets frontend critiques présentant des problèmes de mémoire, avec une gravité critique appliquée aux CWE-125 et CWE-787.
La règle de sécurité Snyk visant à augmenter la criticité des projets front-end critiques présentant des faiblesses liées à la mémoire.

Et pour enrichir davantage les informations de sécurité sur les conteneurs, nous avons ajouté la prise en charge des versions les plus récentes d’Alpine, Debian et Ubuntu, ainsi que de la nouvelle distribution CentOS Stream et d’autres distributions Linux populaires utilisées dans les conteneurs, dès leur publication par leurs responsables. Nous avons également modifié la manière dont nous présentons les vulnérabilités pour Red Hat Enterprise Linux, Amazon Linux et CentOS Stream. Les détails de chaque CVE sont désormais plus précis, avec des informations supplémentaires propres à chaque distribution concernant les niveaux de gravité.

À quoi s’attendre de Snyk Container en 2022

Comme Daniel l’a expliqué dans notre article Bilan 2021 de Snyk Open Source, la sécurisation de la chaîne d’approvisionnement est un sujet de plus en plus important et visible, et les conteneurs en sont un élément majeur. Il devient de plus en plus essentiel de connaître tous les composants présents dans vos propres conteneurs, créés selon vos processus de compilation spécifiques. Mais il faut aussi savoir ce que contiennent les applications tierces fournies sous forme de conteneurs que vous utilisez. Vos conteneurs de bases de données, outils de journalisation et de recherche, répartiteurs de charge, passerelles et autres outils sont probablement déployés aux côtés de vos applications et leur apportent des fonctionnalités essentielles. Ils peuvent toutefois aussi contenir des vulnérabilités dangereuses. Vous devez en être informé et pouvoir déployer de nouvelles versions dès que leurs responsables les publient.

Nous voulons également aller beaucoup plus loin dans la hiérarchisation des vulnérabilités. Cela comprend de nouveaux signaux indiquant qu’un paquet ou une vulnérabilité présente un danger accru, ainsi que davantage de renseignements et des politiques évolutives permettant aux développeurs d’ignorer les vulnérabilités bruyantes qui ne sont pas vraiment pertinentes. En combinant ces deux approches, nous pensons pouvoir aider les utilisateurs de Snyk Container à passer de centaines de vulnérabilités détectées lors d’une analyse à quelques étapes seulement pour corriger les plus urgentes, tout en allégeant la charge manuelle de gestion des vulnérabilités qui pèse sur les équipes de sécurité débordées.

Nous vous souhaitons une excellente année 2022, placée sous le signe de la sécurité !

La sécurité des conteneurs, pensée pour les développeurs

Snyk détecte et corrige automatiquement les vulnérabilités dans les images de conteneurs et les workloads Kubernetes.