Skip to main content

Détecter les vulnérabilités des applications dans les images de conteneurs

Écrit par
Headshot of Danielle Inbar

Danielle Inbar

18 mai 2020

0 minutes de lecture

Snyk facilite encore davantage la détection des vulnérabilités dans les images de conteneurs en identifiant les dépendances vulnérables des applications, en plus des vulnérabilités du système d’exploitation.

Résultats de l’analyse des vulnérabilités du conteneur mladkau/ghost, avec les tags d’image, les chemins des packages, le nombre de vulnérabilités par niveau de gravité et les heures des tests

Perte de provenance et images tierces

Snyk permet aujourd’hui de détecter les vulnérabilités dans les dépendances de vos applications Java, .NET, Python, Go, etc., ainsi que dans vos images de conteneurs. Jusqu’à présent, cependant, ces opérations étaient exécutées avec des commandes distinctes dans notre CLI.

Cette approche fonctionne bien lorsque vous testez les dépendances de votre application, créez des images, puis testez les vulnérabilités du système d’exploitation du conteneur dans le cadre d’un pipeline étroitement intégré. Mais qu’en est-il des images tierces que vous exécutez sans jamais avoir eu accès au code source ? Ou de cette image dans votre registre, dont vous ne savez pas exactement quelle version du logiciel est installée ?

Un seul scan pour détecter toutes vos vulnérabilités

Auparavant, lors du scan d’une image de conteneur, nous affichions quelque chose comme ceci :

Interface Snyk affichant l’image de conteneur daniellsnyk/snykit:latest analysée, le nombre de vulnérabilités et l’horodatage de l’analyse

Vous pouvez voir ici le nom de l’image, une icône représentant le système d’exploitation de l’image de base, ainsi que le nombre de vulnérabilités élevées, moyennes et faibles. Aujourd’hui, le scan de la même image affiche :

Tableau de bord d’analyse de Snyk Container affichant l’image daniellesnyk/snykit:latest et la dépendance /app/Gemfile.lock, avec le nombre de vulnérabilités

Vous pouvez voir ici que nous avons également détecté des applications dans les images et identifié des vulnérabilités dans leurs dépendances.

Cette fonctionnalité s’appuie sur la base de données de vulnérabilités de classe mondiale de Snyk, qui rassemble des vulnérabilités provenant d’un large éventail de sources publiques et privées, notamment les travaux de notre propre équipe de recherche.

Disponibilité

Nous commençons actuellement à déployer cette nouvelle fonctionnalité dans nos intégrations de conteneurs, en commençant par la prise en charge des registres de conteneurs. Si vous utilisez Amazon ECR, Docker Hub, GCR, ACR ou Artifactory, vous pouvez l’utiliser dès aujourd’hui. Nous ajouterons ensuite la prise en charge de notre intégration Kubernetes et de nos outils CLI, mais nous aimons mettre rapidement les nouvelles fonctionnalités à votre disposition.

Nous avons également commencé par prendre en charge un sous-ensemble de langages, principalement des langages dynamiques pour le moment. Python, JavaScript, PHP et Ruby sont actuellement pris en charge. À terme, nous aimerions prendre en charge tous les langages que nous prenons en charge ailleurs.

Pour les nouveaux utilisateurs de Snyk et les utilisateurs disposant d’un compte Snyk gratuit, cette fonctionnalité est activée par défaut. Pour les clients Snyk Container, nous privilégions la prudence, car nous ne voulons pas générer de bruit inattendu dans vos rapports de vulnérabilités dans Snyk. Que vous soyez un utilisateur gratuit ou payant, vous pouvez activer ou désactiver cette fonctionnalité dans la page des paramètres :

Panneau de paramètres permettant de détecter les vulnérabilités des applications dans les images de conteneurs, avec une option d’analyse Snyk et un bouton Enregistrer les modifications

Donnez-nous votre avis

Comme toujours, n’hésitez pas à nous faire part de votre avis sur cette nouvelle fonctionnalité et à nous dire ce que vous aimeriez voir ensuite.

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.