La propriété de l’application de correctif d’une vulnérabilité dans une image de conteneur peut varier d’une organisation à l’autre. Ces informations peuvent être capturées à différents endroits. Certaines organisations utilisent des étiquettes d’image Docker pour identifier les équipes d’application propriétaires d’une certaine image de conteneur, tandis que d’autres organisations peuvent utiliser l’espace de noms Kubernetes ou le compte cloud où une image de conteneur est déployée pour identifier le propriétaire du droit.

Réponse aux vulnérabilités pour conteneurs fournit les éléments de modèle de données nécessaires pour pouvoir capturer et utiliser les étiquettes d’image Docker, les métadonnées de cluster/service/espace de noms Kubernetes ou les métadonnées du compte cloud (ID de compte cloud, région, fournisseur, etc.) dans le module « Règles d’affectation » et affecter automatiquement les vulnérabilités à la bonne équipe d’application en fonction des métadonnées de l’image ou de l’environnement d’exécution.

Par défaut, un élément vulnérable est créé pour chaque combinaison unique de CVE et de la version de l’image Docker (référence + balise). Toutefois, quelques images Docker peuvent être déployées dans plusieurs espaces de noms Kubernetes et chaque espace de noms peut appartenir à différentes unités commerciales ou équipes. Chaque équipe peut suivre sa propre cadence pour déployer de nouvelles versions d’images de conteneurs afin de corriger les vulnérabilités. Pour prendre en charge ce scénario, vous permet de définir la granularité des éléments vulnérables : indique si un élément vulnérable doit être créé pour chaque espace de noms/cluster/service Kubernetes, Réponse aux vulnérabilités pour conteneurs même pour chaque combinaison unique de version et de vulnérabilité de l’image Docker.

Dans l’exemple, vous pouvez voir deux éléments vulnérables créés pour la même combinaison d’image Docker et de CVE. L’un pour l’espace de noms Kubernetes 'k8s-finservco-loans' et l’autre pour 'k8s-finservco-wealthandinsurance'.

Le calcul du risque pour les éléments vulnérables peut être effectué en examinant le CI (image de Docker) et la criticité des services associés dans CMDB. Toutefois, pour faciliter l’identification des services impactés, Réponse aux vulnérabilités pour conteneurs propose une identification des services basée sur les balises.

Lorsque des pods ou des entités Kubernetes sont publiés avec des clés-valeurs ou des étiquettes correspondant aux clés-valeurs définies dans un « service basé sur les balises » dans ServiceNow, Réponse aux vulnérabilités pour conteneurs établit automatiquement la relation entre une image Docker et le service d’application impacté, et utilise la criticité de ce service d’application dans le calcul du risque.

Contrairement aux vulnérabilités de l’hôte qui peuvent être corrigées en appliquant un correctif sur un hôte, les vulnérabilités des conteneurs ne peuvent pas être corrigées. De nouvelles versions des images de conteneurs doivent être créées et déployées pour remplacer les anciennes versions. Les nouvelles versions ont un identifiant différent (ID d’image) par rapport aux versions précédentes, ce qui rend difficile le suivi des vulnérabilités qui ont déjà été corrigées.

ServiceNow identifie les vulnérabilités qui ont été signalées dans les versions précédentes des images de conteneur mais qui ont été résolues dans la dernière version de l’image et déplace automatiquement ces vulnérabilités vers l’état « Fermé/Corrigé » afin que les équipes de sécurité aient toujours une visibilité précise sur la dernière situation en matière de risque.