Contrairement aux applications traditionnelles, les conteneurs regroupent tous les codes sources de l’application ainsi que leurs dépendances dans un fichier binaire appelé image de conteneur. L’image est publiée dans un registre afin de fournir une option permettant d’exécuter cette image en tant qu’application ou instance de conteneur sur n’importe quelle plateforme. Les étapes du cycle de vie de prédéploiement d’un conteneur sont les suivantes :

1. Composer l’image du conteneur : l’image du conteneur est composée et pointe vers un code source ou une bibliothèque dépendante.
2. Créer l’image du conteneur
3. Publier l’image du conteneur : le fichier d’image du conteneur est publié dans un registre. Chaque image a son propre ID unique basé sur le contenu de l’image. Ces images sont extraites du registre vers l’environnement d’exécution en mode post-déploiement. Les images s’exécutent ensuite en tant qu’instances de conteneur sur l’hôte dans l’environnement de production.

Une image de conteneur peut être analysée pour détecter les vulnérabilités avant ou après le déploiement. Si les images de conteneurs sont analysées pendant la phase de pré-déploiement, vous pouvez recevoir de nombreuses alertes de vulnérabilité, qui peuvent ne pas nécessiter votre attention immédiate. Cependant, l’analyse des vulnérabilités pendant la phase post-déploiement offre des avantages plus importants, tels que les suivants :

• Fournir une visibilité sur le risque associé aux applications déployées.
• Fournir une vue ciblée uniquement sur les images dans l’environnement de production.
• Identifier et hiérarchiser les vulnérabilités qui doivent faire l’objet d’une action immédiate.
• Regroupement et affectation des vulnérabilités en fonction des métadonnées de l’image. Par exemple, un référentiel d’images, une étiquette d’image et d’autres attributs associés à l’image du conteneur peuvent être utilisés pour les règles de regroupement et d’affectation.

Chaque image de conteneur comporte les composants clés suivants :

• Référentiel de conteneurs ou d’images : représente l’image de Docker avec un référentiel ou un nom donné. Il héberge toutes les versions de l’image.
• Image de Docker : représente une version spécifique de l’image de Docker de la version.
• Conteneur Docker : représente une instance en cours d’exécution de l’image Docker. Chaque version a un ID unique et possède plusieurs instances des conteneurs en cours d’exécution dans l’environnement de production.

Le Réponse aux vulnérabilités pour conteneurs module fournit des détails sur les éléments suivants :

Résultats (éléments vulnérables du conteneur)

Les résultats (CVIT) sont regroupés et répertoriés en fonction de leur affectation, de leur criticité, de leur exploitabilité et de leur état de rattrapage.

Bibliothèques

Accédez à la base de données de vulnérabilité nationale (NVD) et à des bibliothèques tierces. Alors que la bibliothèque NVD fournit des informations limitées à l’ID de l’élément de vulnérabilité, la bibliothèque tierce fournit la plupart des détails sur un élément de vulnérabilité. Les informations de l’écran NVD ne sont renseignées que lorsque l’intégration NVD est déclenchée.

Administration

Le module Administration fournit des informations sur les règles d’affectation des éléments vulnérables, les règles de cibles de rattrapage et les intégrations de vulnérabilité des conteneurs. En outre, vous pouvez également configurer la durée après laquelle un élément vulnérable doit être fermé automatiquement. Vous pouvez utiliser la section Configurer la granularité VI pour configurer la granularité des CVIT en spécifiant les combinaisons de clés. Par défaut, une CVIT est créée pour une combinaison d’un référentiel d’images, d’une balise d’image et d’une vulnérabilité. Vous pouvez ajouter des composants supplémentaires à la clé pour plus de granularité. Par exemple, vous pouvez créer une CVIT pour une combinaison de référentiel d’images, de balise d’image, de vulnérabilité et de grappe.